Numberly has been using both ScyllaDB and MongoDB in production for 5+ years. Learn which NoSQL database they rely on for different use cases and why. W domenie NoSQL ScyllaDB i MongoDB to dwa zupełnie różne zwierzęta. MongoDB nie wymaga wprowadzenia. i zasilanie niezliczonych aplikacji internetowych. architektura ScyllaDB blisko metalu umożliwia przewidywalne niskie opóźnienie przy wysokiej przepustowości. , i wielu innych, którzy rozwijają się i uderzenie w ścianę z istniejącymi bazami danych. Nośnik Dyskryminacja Traktat Intensywne aplikacje danych Zamiast tego przyjrzyjmy się, w jaki sposób te dwie wyraźnie różne bazy danych mogą współistnieć w ramach tego samego zestawu technologii – w jaki sposób są one zasadniczo różne, a najlepsze przypadki użytkowania dla każdego. Zamiast udostępniać perspektywę dostawcy, będziemy dzielić się wglądami entuzjastów open source, którzy mają duże doświadczenie w wykorzystywaniu zarówno ScyllaDB, jak i MongoDB w produkcji: Alexys Jacob, CTO Numberly. Oto trzy kluczowe przykłady z jego szczegółowego przemówienia technicznego: Scaling Writes jest bardziej skomplikowany w MongoDB Jednostka podstawowa topologii MongoDB nazywa się zestawem repliki, który składa się z jednego węzła podstawowego i zwykle z wielu węzłów wtórnych (myśl o gorących replikach). Tylko węzeł podstawowy jest dozwolony do pisania danych. Po maksymalizacji skali pionowej pisania na MongoDB, jedyna opcja skali pisania staje się tym, co nazywa się klastrem podzielonym. Podział danych na zestawy repliki MongoDB wymaga użycia specjalnego klucza, aby określić, za jakie dane odpowiada każdy zestaw repliki, a także utworzenie zestawu repliki metadanych, który śledzi, jaki kawałek danych żyje na każdej replice (niebieski trójkąt na poniższym wykresie). Ponadto klienci łączący się z klasterem MongoDB muszą pomóc określić, który węzeł ma być adresowany. Złożoność skalowania zapisów w MongoDB Posiadanie wszystkich tych węzłów prowadzi do wyższych kosztów operacyjnych i konserwacyjnych, a także marnowanych zasobów, ponieważ nie można użyć IO węzłów replikacyjnych do pisania, co czyni rozdrobnione klastry MongoDB najgorszym wrogiem całkowitego kosztu własności, jak zauważył Alexys. Dla ScyllaDB skalowanie jest o wiele prostsze. wyjaśnił: „Po stronie ScyllaDB, jeśli chcesz dodać więcej przepustowości, po prostu dodajesz węzły. Alexys powiązał ten sznur skali: „Proszę unikać tworzenia klastrów MongoDB! Mogę napisać książkę z historiami wojennymi na ten sam temat. Głównym powodem jest fakt, że MongoDB nie wiąże obciążenia pracy z procesorami. A rozdrabnianie, dystrybucja danych między zestawami replik w klastrze odbywa się za pomocą pracy w tle (balansera). Ten balanser zawsze działa, zawsze patrząc na to, jak należy wykonać rozdrabnianie, i zawsze zapewniając, że dane są rozproszone i zrównoważone w całym klastrze. To nie jest naturalne, ponieważ nie opiera się na spójnym haszowaniu. Jest to coś, co należy obliczać wielokrotnie. Rozdziela dane na kawałki, a następnie porusza je wokół. To ma bezpośredni wpływ na wydajność MongoDB preferuje elastyczność nad wydajnością, podczas gdy ScyllaDB preferuje spójną wydajność nad wszechstronnością ScyllaDB i MongoDB mają wyraźnie różne priorytety, jeśli chodzi o elastyczność i wydajność. Na froncie modelowania danych MongoDB natywnie obsługuje zapytania geoprzestrzenne, wyszukiwanie tekstu, rurociągi agregacji, zapytania graficzne i przepływy zmian. Chociaż ScyllaDB – magazyn szerokiej kolumny (tzw. klucz-wartość) – obsługuje typy zdefiniowane przez użytkownika, liczniki i lekkie transakcje, opcje modelowania danych są bardziej ograniczone niż na MongoDB. Alexys zauważył: „Z perspektywy rozwoju interakcja z obiektem JSON po prostu wydaje się bardziej naturalna niż interakcja z wierszem”. w celu egzekwowania walidacji schematu przed wprowadzeniem danych, ScyllaDB Dane te są zgodne ze zdefiniowanym schematem. Opcja Wymaga Zapytanie jest również prostsze z MongoDB, ponieważ po prostu filtrować i interakcji z JSON. Jest również bardziej elastyczne, na lepsze lub na gorsze. MongoDB pozwala na wystawianie wszelkiego rodzaju zapytań, w tym zapytań, które powodują nieoptymalną wydajność z obciążenia produkcyjnego. ScyllaDB nie pozwoli na to. Jeśli spróbujesz, ScyllaDB będzie Cię ostrzegać. Jeśli zdecydujesz się postępować na własne ryzyko, możesz wprowadzić kwalifikator wskazujący, że naprawdę rozumiesz, do czego się dostajesz. Alexys podsumował kluczowe różnice z perspektywy rozwoju: „MongoDB preferuje elastyczność w stosunku do wydajności. Łatwo jest z nim współpracować i nie będzie Ci przeszkadzać. Ale będzie to miało wpływ na wydajność – efekty, które są dobre dla niektórych obciążeń roboczych, ale niedopuszczalne dla innych. Z drugiej strony, ScyllaDB preferuje spójną wydajność w stosunku do wszechstronności. Wygląda trochę bardziej stałe i trochę bardziej sztywne na zewnątrz. Ale znowu, to dla własnego dobra, abyś mógł mieć spójną wydajność, działać dobrze i dobrze współdziałać z systemem. Moim zdaniem, to robi prawdziwą różnicę, gdy masz obciążenia robocze wrażliwe na opóźnienie i wydajność.” Ważne jest, aby pamiętać, że nawet zapytania, które przestrzegają najlepszych praktyk wydajnościowych, będą się zachowywać inaczej na MongoDB niż na ScyllaDB. Bez względu na to, jak ostrożny jesteś, nie pokonasz kary wydajności, która wynika z fundamentalnych różnic architektonicznych. Wspólnie ScyllaDB i MongoDB to świetna kombinacja NoSQL "To nie jest mecz śmierci; jesteśmy szczęśliwymi użytkownikami zarówno MongoDB, jak i ScyllaDB" - kontynuował Alexys. Numerally wybiera najlepszą bazę danych dla wymagań technicznych każdego przypadku użytkowania. W Numerly MongoDB jest używany do dwóch rodzajów przypadków użytkowania: Web backend z REST API i ewentualnie elastycznych schematów. Zapytania w czasie rzeczywistym na temat nieprzewidywalnych danych behawioralnych. Na przykład niektóre aplikacje Numberly są zalewane danymi śledzenia sieci Web, które ich klienci zbierają i wysyłają (każdy z własnymi aplikacjami opracowanymi wewnętrznie). Numberly nie ma sposobu na narzucenie ścisłego schematu tym danym, ale musi być w stanie je zapytać i przetwarzać. ScyllaDB jest używany do trzech rodzajów przypadków użytkowania w numerly: Rurociągi danych wrażliwe na opóźnienie w czasie rzeczywistym. Obejmuje to wiele procesów wzbogacania danych, w których istnieje wiele źródeł danych, które muszą być powiązane, w czasie rzeczywistym, na rurociągach danych. Według Alexys, „To trudne do zrobienia... i potrzebujesz silnych gwarancji opóźnienia, aby nie złamać umów SLA [umów na poziomie usług] z aplikacjami i procesami danych, na które opierają się Twoi klienci”. Numerly łączy również wiele obciążeń baterii i obciążeń w czasie rzeczywistym w ScyllaDB, ponieważ zapewnia to, co najlepsze z obu światów (jak numerly udostępnił wcześniej). „Mamy Hive na jednej ścieżce, a MongoDB na drugiej. Niektóre backendy sieci Web firmy Numerly są wdrażane w GraphQL. Podczas pracy z interfejsami API opartymi na schematach ma sens posiadanie bazy danych opartej na schematach o niskim opóźnieniu i wysokiej dostępności. Alexys podsumowuje: „Wielu naszych inżynierów backendowych, a także inżynierów frontendowych, przyjmuje ScyllaDB. Widzimy tendencję osób przyjmujących ScyllaDB, coraz więcej osób z branży technologicznej pyta: „Mam ten przypadek użycia, czy ScyllaDB będzie dobry?” Większość czasu odpowiedź brzmi: „tak”. Bonus: Więcej informacji od Alexys Jacob Alexys jest niezwykle hojnym współpracownikiem społeczności open source, zarówno w odniesieniu do kodowania, jak i rozmów konferencyjnych. https://ultrabug.fr/ o Cynthia Dunlop Cynthia jest dyrektorem ds. Strategii Treści w ScyllaDB. Pisze o rozwoju oprogramowania i inżynierii jakości od ponad 20 lat.
