Rdzeń nie jest wystarczająco konkretny, aby dać jednoznaczną sugestię, ale pełna lista tego, co można zrobić, jest następująca:
- Klaster baz danych :Nadaje się do sytuacji, w których nie chcesz zmieniać warstwy aplikacji, a baza danych jest wszystkim, czego dotykasz. Istnieje limit tego, ile możesz uzyskać z klastra bazy danych. Jeśli liczba żądań będzie nadal rosła, to rozwiązanie również w końcu się nie powiedzie. Ale dobrą wiadomością jest to, że masz wszystkie funkcje, które już miałeś w zwykłym jednoinstancyjnym MySQL.
- Sharding :Ponieważ Twoje pytanie jest otagowane MySQL i samo w sobie nie obsługuje shardingu, jeśli chcesz skorzystać z tego rozwiązania, musisz je zaimplementować w swojej warstwie aplikacji. W tym rozwiązaniu logicznie rozproszysz swoje dane w wielu bazach danych (najlepiej w wielu instancjach MySQL na osobnym sprzęcie). Twoim obowiązkiem będzie znalezienie odpowiedniej bazy danych zawierającej wyznaczone dane. To jedno z najskuteczniejszych rozwiązań w historii, ale nie zawsze jest to wykonalne. Jego największą wadą jest to, że dane rozproszone między dwiema lub większą liczbą baz danych nie mogą być uwzględnione w transakcji.
- Replikacja :W zależności od scenariusza możesz mieć możliwość włączenia replikacji bazy danych i posiadania na nich kopii swoich danych. W ten sposób możesz połączyć się z nimi zamiast z bazą danych master i zmniejszyć jej obciążenie. Domyślną definicją replikacji jest scenariusz typu master/slave, w którym przepływ danych jest jednokierunkowy, od urządzenia nadrzędnego do podrzędnego. Tak więc zmiany, które możesz wprowadzić na niewolniku, gdy zostaną zastosowane na maści, nie wpłyną na mistrza. Ale istnieje również konfiguracja replikacji master/master, w której przepływ danych odbywa się w obie strony. Jednak nie można zakładać atomowej integralności dla równoczesnych zmian danych między obydwoma masterami. Ostatecznie to rozwiązanie jest najskuteczniejsze, jeśli planujesz używać go w trybie master/slave i używać slave'ów do dostępu tylko do odczytu.
- Buforowanie :Być może to rozwiązanie nie powinno być tutaj uwzględnione, ale ponieważ twój rdzeń go nie odrzuca, oto idzie. Jednym ze sposobów zmniejszenia obciążenia bazy danych jest buforowanie danych po wyodrębnieniu. To rozwiązanie może być korzystne zwłaszcza wtedy, gdy wyodrębnianie danych jest kosztowne. Istnieje wiele serwerów pamięci podręcznej, takich jak memcached lub redis . W ten sposób możesz pominąć tak wiele połączeń z bazą danych, ale tylko w celu ekstrakcji danych.
- Inne silniki pamięci masowej :Zawsze możesz przełączyć się na bardziej wydajne silniki, jeśli Twój obecny nie zapewnia Ci tego, czego potrzebujesz. Oczywiście jest to możliwe tylko wtedy, gdy pozwalają na to Twoje potrzeby. Obecnie istnieją silniki NoSQL, znacznie wydajniejsze niż RDBMS, które obsługują sharding natywnie i można je skalować liniowo przy minimalnym wysiłku. Istnieją również rozwiązania oparte na Lucene z potężnymi funkcjami wyszukiwania pełnotekstowego, zapewniającymi to samo automatyczne sharding. W rzeczywistości jedynym powodem, dla którego powinieneś używać tradycyjnego RDBMS, jest atomowe zachowanie transakcji. Ale jeśli transakcje nie są koniecznością, istnieją znacznie lepsze rozwiązania niż RDBMS.
