Udane implementacje VoltDB

Question

Pracuję nad projektem od ponad pół roku, budując oprogramowanie opieki zdrowotnej od podstaw. Kiedy się dołączyłem, MySQL został wybrany jako podstawowy magazyn danych.

Kilka miesięcy i wiele bóle głowy później, zaczęliśmy badać alternatywne sklepy danych, które mogą zaoferować elastyczność potrzebną do rejestrowania naszych krytycznych i stale zmieniających się danych dotyczących opieki zdrowotnej.

Przyjrzeliśmy się wielu rozwiązaniom NoSQL; MongoDB czerpiąc najwięcej z naszej uwagi. Możliwość przechowywania uporządkowanych, osadzonych danych byłaby ogromną korzyścią. Jednak obawialiśmy się raportów o utracie danych/niezawodności.

Natknąłem się na kilka magazynów danych "NewSQL" i jestem zainteresowany VoltDB w szczególności.

Jestem ciekawy, czy ktoś ma jakiekolwiek doświadczenie z Voltem, czy też widział go w projekcie.

Edit:

integralność danych i konsystencja są najważniejsze. Może to być bardzo szkodliwe dla informacji o pacjentach, które mogą zostać utracone, mogą otrzymać niewłaściwą terapię itp.

Objętość danych będzie się różnić; Najpierw prawdopodobnie poprzemy małe praktyki. Coś jak 700 użytkowników łącznie. Ale nawet kiedy zwiększamy skalę do szpitali, nie patrzymy na media społecznościowe, takie jak ruch drogowy.

Jeśli chodzi o twoje pytanie, tak struktury danych będą ewoluować. Oprócz konieczności zmiany istniejącej struktury w celu wychwycenia nowych lub zmodyfikowanych danych wejściowych, musimy zachować strukturę istniejących danych jako swego rodzaju snap-shot. Ten styl EAV udało się nam tylko z MySQL.

Dziękujemy za opinię.

Answer 1

W zeszłym roku wybraliśmy aplikację, która korzysta z VoltDB. Przechowujemy około 1,5 miliarda rekordów i przetwarzamy 50-90 milionów transakcji dziennie z kfactor = 1 4 klastrem serwerów (256 GB pamięci/serwera). Biorąc pod uwagę wydajność VoltDB, z łatwością moglibyśmy przekazać 1 miliard transakcji dziennie.

Do tej pory nie mieliśmy żadnych problemów związanych z oprogramowaniem VoltDB. Nasze doświadczenie jest zgodne z ACID. Dodając funkcję rejestrowania poleceń, uważam, że możesz skonfigurować parametry rejestrowania, aby wykluczyć utratę jakichkolwiek transakcji.

Do innych silnych funkcji należy skalowalność (i względna prostota dodawania pojemności).

Ważnym czynnikiem przy wyborze VoltDB jest zrozumienie schematu partycjonowania VoltDB. Uzyskanie bardzo wysokich szybkości transakcji z VoltDB zależy od równoległości osiągniętej dzięki partycjonowaniu danych. Partycjonowanie jest niewidoczne dla twojej aplikacji, ale dane twojej aplikacji muszą być podzielone na partycje, aby uzyskać maksymalną wydajność. Jeśli twoje dane nie nadają się do partycjonowania, uważam, że podstawowym skutkiem byłaby mniejsza przepustowość (tj. Stawki transakcji) - a nie ogranicznik.

Wreszcie - uwaga dotycząca procedur przechowywanych. VoltDB pozwala na zastąpienie procedur przechowywanych bez zatrzymywania bazy danych. Ponadto każde wywołanie procedury składowanej stanowi pojedynczą transakcję. Zastosowaliśmy procedurę przechowywaną w taki sposób, że jesteśmy w stanie zmodyfikować/zaktualizować naszą logikę aplikacji bez zatrzymywania bazy danych.

Answer 2

Pytanie w obecnym brzmieniu jest bardzo subiektywne, ale więcej informacji może pomóc nam wskazać właściwy kierunek.

Jakie są dokładnie Twoje wymagania? Czy ten system ma potrzeby transakcyjne, gdy integralność i spójność danych ma ogromne znaczenie, na przykład w aplikacjach handlowych i finansowych? Jaka jest objętość danych i ilu współbieżnych użytkowników? Jakie są wymagania dotyczące wydajności?

Wspomniałeś także o ever-changing healthcare data, czy to oznacza, że ​​struktury danych ciągle się zmieniają i ewoluują? Jeśli tak, możesz chcieć trzymać się z daleka od relacyjnych baz danych, biorąc pod uwagę naturę sztywnych schematów, a zamiast tego rozważ magazyny dokumentów, takie jak Mongo, gdzie struktury danych bez użycia schematu zapewniają większą elastyczność.

BTW,

Nie wystraszyli się opowieści o niezawodności na Mongo; można znaleźć horrory dla praktycznie każdego produktu, zarówno open source, jak i komercyjnego; często te złe recenzje mają mniej wspólnego z produktem i mają więcej wspólnego ze słabą implementacją klienta.

VoltDB, ostatnio sprawdziłem, wymaga, aby cała logika trwałości była zakodowana jako procedura przechowywana. Oczywistymi wadami tego podejścia są mniejsza widoczność kodu i modułowość oraz większe potrzeby w zakresie konserwacji. Poza tym Voltdb jest bardzo szybki, ponieważ większość napięć występujących w tradycyjnych relacyjnych bazach danych, takich jak blokowanie itp., Jest eliminowana z silnika bazy danych.

Answer 3

Pytanie jest trochę stary, ale dają pewne informacje zwrotne ponieważ używaliśmy MongoDB od dłuższego czasu, i szukamy do VoltDB ale dla zupełnie różnych powodów:

• chodzi MongoDB : używamy mongoDB w produkcji od 4 lat i nigdy nie straciliśmy ani jednego bajtu danych. "Mongodb nie jest wiarygodny" wydaje się być mitem, przynajmniej dla mnie. Zarządzamy milionami nowych wpisów w mongoDB każdego dnia bez żadnych problemów.

• Szukamy VoltDB do innego zastosowania: dostarczania analiz w czasie rzeczywistym na ogromnym wolumenie. MongoDB nie jest zły w dostarczaniu analiz, ale kiedy przekroczysz liczbę milionów wpisów do analizy, zaczyna być nieco powolny. VoltDB jest o wiele lepszy, ale nie radziłbym ci używać go do przechowywania danych, szczególnie danych o dużej wartości ... Używamy innej bazy danych do przechowywania danych.