NoSQL срещу SQL през 2017 г.

Дойдох на изображението по-горе тук и това ме накара да се усмихвам. Не поради подразбиращата се сложност при избора на база данни, а реалността, с която тази диаграма заснема състоянието на света на базата данни днес през 2017 г. Разбира се, пускането на каквато и да е база данни в крайна сметка изберете в производството е съвсем друг ред на сложност.

Работя по разпределени системи през последните 10+ години. Работил по Касандра, преди тя да е била отворена или дори е била наречена Касандра, и е работила върху HBase във Facebook за куп случаи на използване, съдържащи 100 петабайта данни. Всичко това започна по време, преди NoSQL да е нещо и преди хората да четат за NoSQL срещу SQL, докато техните очни ябълки не изпаднат. Така че исках да споделя някои от моите мисли.

Първоначално RDBMS са били доминиращите бази данни. Нуждаете се от мащаб? Вземете машина за пчелари. Това беше ерата, когато DB2, Oracle, SQLServer, MySQL, Postgres и други станаха популярни. Скоро стана ясно, че чистото мащабиране на RDBMS, като се снабди с машини за подслушване, няма да реши проблема с съхраняването на техните данни - данни, които започнаха да се изсипват като firehose. И дори да се случи по някакъв начин, това би било изключително скъпо.

Естествената следваща стъпка на решението беше да се надгради върху разкъсани бази данни SQL. SQL базата данни с единичен възел беше разделена на множество логически бази данни, данните бяха разделени на приложния слой и репликация / HA, управлявана от оперативния екип. Това означаваше да се откажете от чисто „релационните“ аспекти на RDBMS - като съединения, чужди ключове и т.н. и денормализиране на схемата. Това решение е работещо, макар и очевидно много трудно да се приложи навсякъде (от екипите за разработка на приложения до оперативните екипи).

Ако се замислите, горното решение е много повторяемо - особено ако потребителите на базата данни са се подготвили психически да се откажат от релационните аспекти на RDBMS. Решението може да се изрази много конкретно:

  1. имплицитно изрязване на данни, за да се даде възможност за мащабиране
  2. автоматично копиране на данни, за да оцелеят неуспехите
  3. безпроблемно да се справят с отказите на възлите за предоставяне на HA (използвайки реплики)
  4. позволяват прост начин за изразяване на заточване, запитвания, репликация

За да се предостави горното решение, се създават базите данни „NoSQL“. Но базите от първо поколение се съсредоточиха много върху езика, използван за изразяване на изостряне и запитвания, и недостатъчно върху стабилността, съгласуваността и репликацията на данните / гаранциите на HA. Определението на NoSQL от Wikipedia от тук е:

База данни NoSQL (първоначално отнасяща се до „не SQL“ или „нерелационна“) [1] база данни осигурява механизъм за съхранение и извличане на данни, който се моделира по начин, различен от табличните връзки, използвани в релационни бази данни.

Така фокусът бързо се превърна в това как SQL като език не е идеален и как се нуждаете от различен програмен API с понятия като байтови ключове, колони, фамилии колони и др. Постоянството, репликацията и HA гарантира по някакъв начин се изгубиха във всичкото объркване , което води до бази данни, които не са съвсем работещи за системите за производствен клас. И за да търка сол върху тази рана, някак си Redis се класифицира като база данни на NoSQL - винаги го смятам за Memcache ++. Благодарение на всичко това, за крайния потребител, който прави своите изследвания за това, каква система да използва, пространството на базата данни е изключително сложно.

Вместо NoSQL да бъде „не SQL“ бази данни, фокусът трябваше да бъде върху „нерелационни SQL“ бази данни (да, името не звучи твърде готино). Хората разбраха, че промяната на парадигмата на заявките не би трябвало да е основният фокус. И така, куп бази данни бяха изградени или подобрени с език, подобен на SQL, и терминът NoSQL прост се промени на „Не само SQL“. Проблема решен? Не съвсем - последователността, репликацията и гаранциите за НА все още не са разгледани.

И така, стигаме до днес, когато разкъсани (или мащабирани в някои случаи) SQL бази данни са най-надеждните за стартиране на критични OLTP приложения. NoSQL бази данни (и Redis) се използват заедно с тях за непрекъснато нарастващи набори от данни или по-бърз достъп до данни. Това прави работата на инфраструктурата на данните в производството много трудна, тъй като има множество системи и данните трябва да бъдат синхронизирани през тях. И ако се движите в множество региони / DC или в облачна среда, "много трудно" е голямо подценяване.

Актуализация: Един от читателите попита за това как клъстерно SQL решение се вписва във всичко това. Това е чудесен въпрос.
Ето линк, описващ какво е клъстерно SQL решение: https://www.brentozar.com/archive/2012/02/introduction-sql-server-clusters/
Разделът за това какво клъстериране не помага в горната връзка е уместен.
1. Клъстерирането няма да подобри вашето представяне. Така че това не е решение за мащабиране, а решение за мащабиране с HA
2. Клъстерирането не ви спестява място или усилия за архивиране или поддръжка. Така че не прави нещата оперативно лесни
3. Клъстерирането също няма да ви помогне да мащабите своите показания. Отново не е мащабно решение.
4. Клъстерите няма да ви осигурят 100% продължаване. Така че по-високото ниво на HA, но все пак има ръчни битове.
Следователно клъстерирането попада в категорията „мащабиране нагоре“. Клъстеризирането може да се комбинира с ръчно заточване, за да се постигне мащаб и HA, но е изключително сложно решение за изграждане.

Бихте ли искали да чуете от хора, които тичат или да мислят за пускане на шейниран SQL и / или NoSQL в производството - какви са вашите мисли? С какви проблеми се сблъсквате?