Dlaczego wymyślanie własnej bazy danych pod Twój startup SaaS nie ma najmniejszego sensu

108 silników baz danych NoSQL, tyle, wraz z ich cechami wylicza portal bigdata‑madesimple.com. Jakieś 30 tylko najważniejszych baz typu SQL listuje softwaretestinghelp.com, Wikipedia nie ogranicza aż tak bardzo i podaje listę aż 60 silników SQL. Jeszcze dalej idzie portal db-engines.com co miesiąc porównujący 331 silników.

Bazy SQL są popularne już od kilku dekad. W 1974 r. IBM rozpoczął opracowywanie System R , projektu badawczego mającego na celu opracowanie prototypowego RDBMS. Jednak pierwszym komercyjnie dostępnym RDBMS był Oracle, wydany w 1979 r. przez Relational Software, obecnie Oracle Corporation.

Pomysł nierelacyjnych baz danych nie jest również nowy, a wykorzystanie nierelacyjnych repozytoriów rozpoczęło się w czasach pierwszych komputerów. Nierelacyjne bazy danych rozkwitały w latach 60. XX wieku, w czasach komputerów mainframe, a później, w momencie dominacji relacyjnych baz danych DBMS, znalazły zastosowanie w wyspecjalizowanych repozytoriach, na przykład w hierarchicznych usługach katalogowych. Pojawienie się nierelatywnego systemu DBMS nowej generacji wynikało z potrzeby stworzenia równoległych systemów rozproszonych dla wysoce skalowalnych aplikacji internetowych, takich jak wyszukiwarki internetowe.

NoSQL zyskał popularność na początku XXI wieku, gdy pojawiły się nowe potrzeby firm Web 2.0, takich jak Facebook, Google i Amazon.com, Netflix, Yahoo, eBay, Hulu, IBM i wiele innych.
Termin NoSQL natomiast po raz pierwszy został użyty przez Carlo Strozziego w 1998 roku jako nazwa dla lekkiej relacyjnej bazy open source Strozzi NoSQL.
Wyróżniamy kilka głównych typów NoSQL, np. na podstawie modelu danych:

1. bazy klucz-wartość (ang. key-value) – są najmniej skomplikowanymi implementacjami NoSQL. Są to tabele, które zawierają dwie kolumny tekstowe. Pierwsza kolumna to klucz, druga zaś wartość. Przykłady takich baz to: BerkeleyDB, LevelDB, Memcached, Project Voldemort, Redis, Riak,
2. bazy kolumnowe (ang. column oriented stores) – w tym modelu zamiast w wierszach, dane zapisywane są w kolumnach. To rozwiązanie jest stosowane do przechowywania dużych ilości danych. Przykładowe bazy danych to MongoDB i CouchDB, Orient DB oraz baza w systemie IBM Domino,
3. bazy oparte na grafach (ang. graph stores) – Najpopularniejszą bazą tego typu jest Neo4j. Bazy te oparte są na teorii grafów. Przykładami takich baz są Versant, Objectivity, db4O, EyeDB, a także SBQL,
4. inne bazy danych – zazwyczaj stanowią hybrydę kilku z wyżej wymienionych. Takie podejście jest wykorzystane np. w bazie OrientDB,

Wiele z tych silników rozwijanych jest przez potężne organizacje, pracują nad nimi rzesze inżynierów i najwyższej klasy specjalistów. Powstają narzędzia do zarządzania nimi, mechanizmy są optymalizowane.

Wiele z tych silników zrzesza ogromne społeczności wspomagające się w razie problemów, ludzi doradzających sobie nawzajem optymalne rozwiązania. Są one “sprawdzone w boju” w tysiącach projektów.

W takiej ilości opcji każdy znajdzie coś dla siebie. Słysząc więc, że ktoś decyduje się na stworzenie własnego silnika baz danych, nie sposób nie zadać sobie pytań:

• czy na pewno tworzenie silnika baz danych to nasz core business?
• czy na pewno żadne z kilkuset ugruntowanych rozwiązań na rynku nie spełnia naszych oczekiwań?
• czy jesteśmy w stanie konkurować z ogromnymi środkami wkładanymi w rozwój istniejących baz danych?
• czy jesteśmy w stanie zapewnić podobną ilość narzędzi, wsparcia w razie sytuacji problematycznych jak inne, gotowe rozwiązania?
• czy stać nas na tracenie tak dużych zasobów osobowych deweloperskich?
• czy świadomie ignorować możemy fakt społeczności wspierających aktywnie inne projekty? Ludzi, którzy doświadczyli praktycznie wszelkich możliwych problemów i znaleźli dziesiątki na nie rozwiązań?

Oczywiście każdy powie, że jeżeli nikt nie postanowił by stworzyć własnej bazy danych nie powstały by wspomniane rozwiązania. Ale śpieszę wyjaśnić – w większości to core business dla firm tworzących poważne silniki bazo-danowe. Google stworzył BigQuery – ale to, poza wykorzystaniem wewnętrznym w wielu projektach, element jego oferty w ramach usługi Google Cloud – a więc komercyjny produkt. Inne firmy, które ewentualnie z sukcesem decydują się na takie rozwiązania, poza core swojego biznesu to giganci jak np. Facebook, którzy przeznaczają ogromne środki finansowe i całe zespoły na te projekty, firmy, które taką na działalność mają praktycznie dowolne zaplecze finansowe i technologiczne.

Osobiście znane są mi takie przypadki jak “stworzenie własnej bazy danych” dla produktu, gdyż, tu cytat “żadna nie jest na tyle doskonała by sprostać oczekiwaniom autora programu” tworzącego produkt – jak dziś pamiętam smak Guinnessa w Slattery’s gdzie świętowaliśmy usunięcie ostatniej jej linijki kodu, przeplatającego się z produktem (no bo jak inaczej mogło się to potoczyć?) – a proszę mi wierzyć, tam świętowaliśmy tylko wyjątkowe wydarzenia, bo znacznie bliżej było jakieś 10 innych Pub’ów.

Więc czy napisanie własnej bazy ma sens? Tak. Pierwsza sytuacja to jeżeli autorska baza danych to produkt, który chcesz sprzedawać, z którego chcesz uczynić swój biznes – i tylko gdy pewny jesteś, że wypełniasz konkretną lukę na tak zatłoczonym rynku i jesteś równie przekonany że zainteresujesz nim odpowiednią jego część.
Druga sytuacja, to taka, w której stać Cię na zainwestowanie ogromnych pieniędzy, w produkt ogromnego ryzyka, który ma nikłe szanse rozwiązać Twoje problemy – a koniec końców z którego prawdopodobnie zrezygnujesz tak jak Facebook zrezygnował z Cassandry tam gdzie oryginalnie została zbudowana (używa teraz HBase).