Оригинал статьи ^[1] 13.12.2014. Джон Эванс, Колумнист TechCrunch.

История из силиконовой долины

Базы данных — это хребет ИТ индустрии: невоспеты, невидимы, но критичны. И крайне пагубны когда они ломаются или деформируются. Это делает специалистов по БД осторожными. Годами только лишь Большая Троица — Oracle, IBM DB2, и может быть SQL Server — были единственными серьёзными опциями. Потом open source альтернативы — MySQL, ProstgreSQL — стали жизнеспособным. А потом, в течение последних пяти лет, всё стало очень интересно…

Немного истории.

На рубеже тысячелетия больше и больше людей стали понимать, что формальные, структуризированные, нормализлванные ^[2] базы данных, запрашиваемые посредством подмножества языка SQL ^[3], чаще затрудняют чем упрощают разработку. В течение последних 10-ти лет появилось множество новых баз данных, особенно в недрах Google, у которых была особенная нужда в распределённых хранилищах данных, — как резльтат BigTable ^[4], Megastore и Spanner ^[5].

Тем временем Apache принесла нам Cassandra ^[6], HBase ^[7], и CouchDB ^[8]; Citrix предложил plug-and-play распределённую замену MySQL ^[9]; Redis стал фундаментальной частью множества Ruby on Rail (и подобных) приложений; и особенно MongoDB ^[10] стал очень популярным среди стартапов не смотря на шумную критику ^[11] — в частности write lock, который не давал параллельно записывать всему кластеру. Это, к счастью, скоро будет исправлено ^[12], что приведёт к немалому ликованию. (Для справки: я разработчик, и делал кое-какую работу с MongoDB, и я не фанат.)

Интересно, что эти новые разработки — так называемые NoSQL «базы данных» — были передовыми стартапами, и совсем мало подобных мечтателей воспринимало их работу серьёзно. Базы данных слишком критичны, в конце то концов. Если ваша БД деформирована, то вы в большой заднице. Если ваша БД не гарантирует целостность ваших данных и ваших транзакций (например, если она не поддерживает то, что называют "ACID транзакции ^[13]"), то настоящие инженеры баз данных не воспримут её серьёзно.

You may not need ACID guarantees but if a storage engine can't provide AD it's basically not a storage engine worthy of your time or data.

— Kelly Sommers (@kellabyte) 11 декабря 2014 ^[14]

Yet we keep benchmarking storage engines that shit themselves and corrupt their own data with ones who don't. Why even benchmark brokenness.

— Kelly Sommers (@kellabyte) 11 декабря 2014 ^[15]

ACID

MongoDB не ACID совместима ^[16]. Аналогично Cassandra, Riak, Redis, и т.д. Кстати говоря, иногда даже утверждали, что NoSQL базы данных фундаментально ACID не совместимы. Это не правда. Google Megastore фактически ACID совместима ^[17], а их Spanner даже лучше ^[18]. Но вы не можете воспользоваться Megastore вне Google, если, конечно, вы не собираетесь создать ваше приложение полностью на их своеобразной платформе App Engine.

Вот почему я был сильно заинтригован пару лет назад, когда наткнулся на будку в TechCrunch Disrupt, чей слоган был «NoSQL, YesACID». Её занимала компания под названием FoundationDB ^[19], которая создала великолепное ACID совместимое ^[20]1 хранилище ключей-значений, поверх которого предоставляется доступ через т.н. SQL слой ^[21]. Неделю назад они анонсировали релиз ^[22] FoundationDB 3.0, которая в 25 раз быстрее чем предыдущая версия благодаря тому, что они называют «пересадка сердца и лёгких» двигателю (engine).

Это серьёзный подвиг в инженерии ^[22]. Цитируя их пост в блоге, это не просто 14 миллионов записей в секунду, это 14 миллионов записей в «полностью упорядоченной, полностью транзакционной базе данных со 100%-ными мульти-ключевыми (multi-key) много-нодовыми (multi-node) транзакциями [...] в облаке [...]. Другими словами, FoundationDB может делать 3,6 миллионов записей за 1 цент.»

Впечатляет. Достаточно впечатляет, чтобы привлечь внимание индеженеров баз данных из Enterprise сферы. И, естественно, идеально подходит для приближающегося Internet of Things, и огромного количества количества данных, которые будут постоянно геренироваться различными девайсами.

Но, что самое важное, — это подстегнёт их конкурентов к бОльшим достижениями, которые, в свою очередь, подтолкнут огромное количество предприятий, застывших в Бронзовом Веке, использующих Oracle и DB2, к, может быть, медленному, аккуратному переезду на современные день. День, в котором разработчики избалованы простыми хранилищами ключ-значение, мощными запросами классического SQL, и распределёнными ACID транзакциями одновременно.^А В далёкой перспективе это сделает жизнь лучше. А пока что снимаю шляпу перед невоспетыми инженерами баз данных, которые где-то там толкают двигатель прогресса ^[23]. Вы себе этого не представляете, но они делают нам огромную услугу.

---

¹
Если вы походите по ссылкам, то они намерено упускают описание буквы «С» в аббревиатуре ACID. Но для точности скажу, что они имеют в виду strong consistency, а не eventual consistency.

---

(От переводчика)
^А
Где-то я видел твит, что ребята работают над Document Layer. Надеюсь, что он будет MongoDB совместимым.

Это первая статья из приближающего цикла статей про FoundationDB. Держите руку на пульсе.

Автор: koresar

Источник ^[24]