Infrastruktura dla wysoce współbieżnego, wysokiego zapisu DB

Moje wymagania to:

• 3000 połączeń
• 70–85% Zapis a odczyt

Obecnie maksymalizujemy bardzo dużą, bardzo dużą instancję przy 700 połączeniach. Wszystkie 8 rdzeni są maksymalne. Uważamy, że jest to liczba równoczesnych połączeń, ponieważ pamięć jest w porządku. Sam zapis jest bardzo prosty (sprawdzanie poprawności spowalnia rzeczy). Aby skalować do 3000, musimy przejść do wielu serwerów, aktualne opcje:

• Sharding MySQL
• Klaster MongoDB
• Cassandra
• Hadoop i MySQL (pamięci podręczne Hadoop, pojedynczy zrzut do MySQL)
• MongoDB i MySQL (zamiast Hadoop używamy mongo do pamięci podręcznej)

Aby obsłużyć tę liczbę połączeń, należy odpowiedzieć na kilka pytań:

1. Czy fragmentowanie MySQL może obsługiwać jednoczesne połączenia?
2. Czy każdy pojedynczy master może obsłużyć te współbieżne połączenia, czy może lepszym rozwiązaniem jest wielogłowicowy Mongo?

Przepraszam, jeśli nie opisuję dobrze mojego problemu. Proszę zadawać pytania

Jeśli używasz MySQL jako głównej bazy danych, możesz rozważyć użycie topologii gwiazdy za pośrednictwem replikacji MySQL.

Teraz, zanim powiesz UGHHH, ROFL i OMG replikacji MySQL, wysłuchaj mnie.

Topologia gwiazdy pozwala pisać na jednym serwerze DB (zwanym Distribution Mster [DM]) i wysyłać polecenia SQL do kilku serwerów DB. Jak skonfigurować taką infrastrukturę DB?

Oto opis

Masz 5 serwerów DB (serwer A, B, C, D, E)

Serwer A

• W konfiguracji replikacji MySQL będzie to Master
• Odgrywa szczególną rolę jako DM
• Mistrz serwerów B, C, D, E
• Wszystkie tabele używają silnika pamięci BLACKHOLE (/ dev / null)
• Przechowuje tylko dzienniki binarne
• Maszyna z gołego metalu
• Korzyści
  • Bardzo szybki zapis, ponieważ wszystkie tabele na DM używają BLACKHOLE
  • Opóźnienie sieci jest mniejszym problemem, ponieważ odczyty stanowią 15-30% aktywności DB
  • Wszyscy niewolnicy są aktualizowani wyłącznie z DM

Serwery B, C, D, E

• Niewolnik A.
• Serwer stanowi bazę dla ciężkich SELECT
• Serwer może być wirtualny lub goły
• Dla wszystkich serwerów, których tabele użytkowników korzystają z silnika pamięci InnoDB
  • Może być serwerem jako ciepły, rezerwowy serwer DB
  • Można na nim uruchamiać nieinwazyjne kopie zapasowe
• Dla wszystkich serwerów, których tabele użytkowników korzystają z silnika pamięci MyISAM
  • Skonfiguruj z opcją tylko do odczytu
  • Tabele mogą mieć zmienione formaty wierszy w celu przyspieszenia odczytów

Pisałem o tym posty wcześniej

• /server/264374/mysql-in-star-topology/264444#264444
• /programming/5273043/mysql-in-star-topology/5781504#5781504

Aby utrzymać replikację MySQL w najwyższej formie

• Użyj MySQL 5.5
• Użyj replikacji półsynchronicznej
• Dostrój InnoDB, aby zaangażować więcej procesorów

Klaster MySQL może być innym podejściem do dzielenia na fragmenty. Sprawdź post tutaj .

Jestem także wielkim fanem Cassandry, ale zależy to w dużej mierze od modelu danych i zapytań, które chcesz wykonać. Cassandra płonie błyskawicznie do pisania, ponieważ zawsze są one sekwencyjne na dysku.

Jeśli zamierzasz przejść na wiele sposobów (co prawdopodobnie potrzebujesz, jeśli naprawdę potrzebujesz aktywnych połączeń 3K), prawdopodobnie spojrzałbym na Riaka lub może Cassandrę. To naprawdę zależy od tego, co robi Twoja aplikacja, co do tego, jak dobrze będą pasować, ale z tego, co opisałeś, myślę, że pasowałoby do czegoś takiego jak Riak.

To powiedziawszy, podejście podzielone na fragmenty wydaje się całkiem wykonalne, jeśli można znaleźć dobry sposób na segmentację danych i zminimalizować potrzebę korzystania z różnych elementów. Trzymałbym się z daleka od jakiegokolwiek pierścienia / gwiazdy / mmm w mysql i po prostu trzymałem się prostego dzielenia. W rzeczywistości, jeśli chcesz korzystać z Postgres, możesz łatwo prototypować za pomocą schematów na czymś takim jak heroku, a następnie rozwidlać i rozdzielać bazy danych, gdy zaczynają przerastać poszczególne węzły.

Aha, i chociaż myślę, że możesz spróbować skalować coś takiego w pionie (pojedynczy węzeł obsługujący wszystkie połączenia 3K), nie sądzę, że możesz to zrobić w chmurze.

Jeśli jest to opcja dla Twojej konkretnej aplikacji, być może możesz użyć jakiegoś asynchronicznego sposobu zapisywania danych do bazy danych (kolejka robocza, wstawki wsadowe ...) i / lub odsuń wiele połączeń klientów z bazy danych z pewnym serwerem proxy z przodu .

Dzięki shardingowi możesz ogólnie dobrze skalować (2x serwery db == 2x połączenia), ale w dużym stopniu zależy to od charakteru zestawu danych i tego, jak możesz podzielić go na części.

Osobiście wolę MongoDB ze względu na łatwość administracji, skalowalność i ogólną łatwość użycia. Ponadto, chyba że rzeczywiście potrzebuję RDBMS, użyję bez SQL.

Powiedziawszy to, wybierz DB, który jest najbardziej odpowiedni dla twojej aplikacji. Jeśli potrzebujesz Transakcji lub nie możesz zaprojektować aplikacji bez połączeń (lub jest to po prostu bardziej sensowne), użyj RDBMS (MySQL, PostGres itp.)

Chociaż osobiście wolę MongoDB, pomysł, że MySQL nie skaluje się lub nie obsługuje wysokiego wskaźnika transakcji, jest całkowicie fałszywy. Zespół inżynierów Facebooka (i zespół MySQL w nim) zajmuje się tym bardzo szczegółowo. Sprawdź także blog zespołu Etsy Ops; kochają również MySQL.

Wreszcie, nie użyłbym MongoDB do pamięci podręcznej MySQL; użyj do tego Memcached.

Redis to także magazyn kluczy i wartości w pamięci RAM, który jest dobry do obsługi niektórych przypadków użycia. Istnieje kilka wpisów na blogu na blog.agoragames.com, które opisują niektóre przypadki użycia.

Powinieneś również sprawdzić CouchDB, jeśli myślisz o braku SQL. Wystarczy mieć świadomość, że wymaga regularnego maint aby utrzymać go w dół wykorzystania dysku. (Wymienia szybkość i wygodę użytkowania dysku ...)

Wreszcie, planowanie wydajności nie jest łatwe do przewidzenia. Musisz przeprowadzić test w możliwie najbardziej realistycznych warunkach i przygotować się na naprawę w oparciu o to, co widzisz. Niestety „informatyka” to tak samo sztuka jak nauka.