2012-05-10 11 views
11

Jesteśmy małym startupem z aplikacją SAAS do pisania, która jest (wreszcie!) Dociera do punktu, w którym nasze użycie przedstawia skalowanie problemów. Mamy mały zespół, więc naprawdę doceniamy możliwość przeniesienia sysadmin do Heroku i RDS.NewSQL kontra tradycyjna optymalizacja/odłamywanie

Podczas Heroku jest (w większości) w porządku, mamy kilka problemów z RDS:

  1. skalowania. To jest największy problem. Obecnie uruchamiamy instancję XLRDS. Będziemy mogli przez jakiś czas korzystać z prostych optymalizacji, ale jeśli nie wprowadzimy poważnych zmian strukturalnych w naszej aplikacji, w pewnym momencie natrafimy na wąskie gardło.

Przerwa w wymianie czasu na zmianę rozmiaru instancji.

  1. Dostępność. Uruchomiliśmy instancję z wieloma AZ, więc powinniśmy przetrwać pojedynczą awarię AZ. Ale RDS jest zbudowany na EBS, co sprawia, że ​​jestem bardzo zmartwiony biorąc pod uwagę historię i projekt EBS.

  2. Cena. Nasz rachunek RDS to 4x to, za co płacimy Heroku. Nie mam nic przeciwko płaceniu Amazonce za uratowanie mnie przed zatrudnieniem sysadmin, ale chciałbym znaleźć coś mniej kosztownego.

Moim zdaniem, mamy dwie opcje do przodu: tradycyjne podejście (sharding, prowadzenie nocną pracę przeniesienie części naszej bazie danych tylko do odczytu, itd.); lub rozwiązanie NewSQL (Xeround, VoltDB, NimbusDB, itp.).

Tradycyjne plusy: Robiono to już wiele razy i istnieją dość standardowe sposoby, aby to zrobić.

Tradycyjne minusy: zajmie to dużo pracy i wprowadzi znaczną złożoność do aplikacji. Nie rozwiąże też problemów wtórnych z RDS (dostępność i cena).

Programiści NewSQL: Podobno rozwiązania te będą skalować poziomo naszą bazę danych bez zmiany kodu aplikacji (z zastrzeżeniem kilku ograniczeń dotyczących funkcji SQL, takich jak brak pesymistycznego blokowania). To zaoszczędziłoby nam ogromnej ilości pracy. Poprawiłoby to również niezawodność (brak pojedynczego punktu awarii) i obniżyło koszty (nie trzeba uruchamiać instancji XL poza godzinami pracy, aby zapewnić maksymalne wykorzystanie).

Wady NewSQL: rozwiązania te są stosunkowo młode i nie udało mi się znaleźć żadnych dobrych opinii ani zapisów dotyczących doświadczeń użytkowników w aplikacjach produkcyjnych. Znalazłem tylko jeden dostępny jako rozwiązanie hostowane (Xeround), więc jeśli nie pójdziemy z tym, będziemy musieli zainwestować zasoby w sysadmin.

Zastanawiam się, jakie są opinie na temat tego, jaki byłby mój najlepszy wybór.

Xeround jest niesamowicie kuszący (hostowany NewSQL), ale nie byłem w stanie znaleźć żadnego dobrego wykorzystania informacji w jego produkcji. Kilka tweetów, które widziałem, to ludzie narzekający na to, że jest trochę powolny. Jestem dość nerwowy, aby przejść do czegoś, co wydaje się tak niesprawdzone.

Konserwatywna strona mnie mówi, że trzymam się RDS i stosuję tradycyjne podejście. Ale będzie to naprawdę drogie pod względem czasu deweloperów.

A potem część mnie zastanawia się, czy jest inny sposób, może bardziej przetestowane w walce rozwiązanie NewSQL, o którym nie słyszałem. A może rozwiązanie NewSQL, które będziemy musieli hostować, ale ma naprawdę solidną historię.

Z góry dziękuję za uwagi.

Odpowiedz

0

W Jingit (www.jingit.com) mamy testowany VoltDB. To fantastyczne w skalowaniu pisania ciężkich aplikacji oraz w chmurze AWS. Nie ma hostowanej opcji, więc nasi deweloperzy są jej właścicielami i spędzają < 1 godzinę tygodniowo administrując naszym klastrem VoltDB. W rzeczywistości używamy zarówno RDS, jak i VoltDB. RDS dla naszego tradycyjnego relacyjnego obciążenia pracą i VoltDB dla naszego przetwarzania transakcji HIGH VOLUME. Jeśli programujesz w Javie, VoltDB doskonale pasuje do pisania wszystkich procedur w Javie.

1

Nie jestem pewien, czy słyszałeś jeszcze o NuoDB. Ale jest to zupełnie nowe rozwiązanie SQL, które oferuje skalowalne możliwości NoSQL i SQL ACACID zgodności tradycyjnego tradycyjnego OLTP. Powinieneś przyjrzeć się rozwiązaniu.

0

Słyszałem także, że NuoDB jest interesujący. Jedną z rzeczy, które słyszę, jest to, że Rackspace wkrótce pojawi się także w chmurze DBaaS. Nie wiem, jakiego smaku będą używać, ale możesz zobaczyć, jak Nuo działa z nimi jako skalowalne rozwiązanie. Myślę, że będzie działać w połączeniu z platformą Open Stack, która po otwarciu może być bardziej kosztowna i wydajniejsza pod względem obliczeniowym. Po prostu coś, na co sam się przyglądałem.