Новая новая вещь (The new new thing)

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

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


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

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

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

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

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




    ACID

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

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

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

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

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



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



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

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

    Ну. И что?
    Реклама
    Комментарии 33
      0
      Проблема ACID в том, что нельзя обойтись без fsync на каждом запросе, что больно. Ну, либо реплицировать с подтверждением, что еще медленнее.

      Если отказаться от обязательной durability, 14 миллионов записей на кластер не особенно впечатляют. Можно делать 20-30 на одном сервере. Не durable это будет только в случае power off сервера. Но тут, не забывайте, что даже используя полностью ACID хранилище, не факт, что логика сервера и вообще распределенной системы готова к power off. А если все-таки готова, ну пайплайните запросы на два полностью дублирующихся сервера, которые потом пайплайнят результаты в один приемник, с отбросом дублей. Таким образом, с двух серверов можно получить что-то близкое к толщине канала / размер среднего сообщения, потому что, что-то мне подсказывает, тут узким местом будет не хранилище. В тесте FoundationDB были примерно 70-байтные сообщения.

      P. S. Я не стою из себя мега-гуру, излагаю свои мысли. Смело тыкайте, если я что-то где-то принципиально ошибаюсь
      0
      Читал о FoundationDB еще когда не было SQL layer.

      Правильно ли я понял, что FoundationDB — это не БД, а движок, который будет поддерживать множество моделей хранения данных?
        0
        В чем разница между БД и «движком»?
          0
          Я имею ввиду, что FoundationDB позволяет выбрать между несколькими типами хранения данных. Нет?
            +1
            Тип хранения данных там, похоже, один — key-value, а поверх него «SQL Layer» который просто что-то типа высокоуровнего интерфейса. Но я бы и то, и другое назвал «БД», а точнее, как бы, вместе. Я, кстати, не специалист по FoundationDB, могу ошибаться.
          0
          Да, именно так. Этот «движок» — обычное key-value хранилище. Ключи-значения можно записывать/читать внутри одной транзакции. Писать свой слой довольно просто. foundationdb.com/key-value-store/documentation/data-modeling.html
          +1
          Архитектурное ограничение в 5 секунд на запрос выглядит немного странным… Или я не до конца разобрался?
          +1
          Конечно цены заломили немного ;(
            0
            Чем оно лучше, чем, например, OrientDB?
              +1
              На вскидку.
              • Перфоманс выше.
              • Можно создавать своё АПИ (aka layer) на любом языке программирования (не только java).


              Чем оно хуже.
              • Как минимум ценой.
              • Нет приятного UI (хотя можно заюзать любую тулзу для администрирования SQL DB).
                0
                На сколько выше? Есть тесты поглядеть? Кстати, как у неё с «отношениями»? Через джойны как в rdbms?

                Админка в OrientDB только выглядит симпатично. Пользоваться ей довольно не удобно.
                  0
                  Такое понятие как «отношения» в FDB отсутствует. Это key-value store.
                  Тогда как в слоях (layers) можно создавать любые отношения между вашими данными (ключами-значениями). Вы не привязаны к какой-то одной модели хранения данных.

                  Например в SQL слое можно использовать стандартный ANSI SQL. Вот пример джойнов: foundationdb.com/layers/sql/documentation/Concepts/table.groups.html#executing-sql-queries
                  Этот слой поддерживается целым ворохом ORM-ов: foundationdb.com/layers/sql/documentation/GettingStarted/index.html#using-an-orm

                  К сожалению я не нашел тестирования перфоманса OrientDB.
                    0
                    С переходом на графовую модель, я вспоминаю об ОРМ и джойнах как о страшном сне.

                    Пример по ссылке:
                    SELECT *
                    FROM customers
                      INNER JOIN orders on customers.customer_id = orders.customer_id
                      INNER JOIN items on orders.order_id = items.order_id;
                    


                    Аналогичный запрос на графе:
                    SELECT FROM customers FETCHPLAN orders.items:0
                    


                    При этом вернётся не табличка, где данные кастомеров, ордеров и айтемов идут вперемешку, как в RDBMS, из которой потом надо ещё группировать айтемы по ордерам и по кастомерам. А вернётся json со списком кастомеров, в каждом из которых будет список ордеров и в каждом из которых будет список айтемов.

                    Почему же вы утверждаете, что FDB быстрее? Потому, что написана на C++?
                      0
                      Разработчики предлагают использовать ORM вместо SQL по возможности.

                      Ещё что мне очень нравится, — транзакции можно писать на любом языке программирования, не только SQL. Вот пример на Java — foundationdb.com/layers/sql/documentation/GettingStarted/Hibernate.html#working-with-hibernate

                      Перфоманс FDB можно посмотреть здесь: foundationdb.com/key-value-store/performance
                        0
                        ORM сгенерирует ещё более чудовищные запросы, которые будут ещё больше тормозить.

                        Да как бы любую субд может использовать из разных языков программирования.

                        Попугайчики — это, конечно, хорошо. Но куда интересней было бы увидеть сравнение с другими решениями.
                          0
                          Могу предложить пока что сравнение надёжности баз данных:
                          blog.foundationdb.com/call-me-maybe-foundationdb-vs-jepsen
                          В самом низу статьи найдёте TL;DR таблицу. Она довольно показательна.
                            0
                            Описание ролей довольно странное. По нему получается, что либо выход из строя CC остановит весь кластер (все ноды будут думать, что они отрезаны от кластера), либо при разделении сетей должно образоваться всё же два кластера.
                            В OrientDB всё куда проще.
                              0
                              Только выход из строя большинства (простого математического большинства) нод-координаторов остановит весь кластер.
                              Что такое СС?
                                0
                                CC — Cluster Cordinator.
              0
              … пару лет назад, когда наткнулся на будку в TechCrunch Disrupt, чей слоган был...

              Excuse me, what? Новый термин?
              (upd: а, понял, имелся в виду стенд).
                0
                Да, слово booth.

                Если есть ещё замечания, пишите личными сообщениями. Я всегда отвечу. :) Спасибо за помощь.
                0
                То ли ещё будет! Если я правильно понимаю, то в Этериуме используются еще интереснее структуры данных которые уже из коробки интегрированы со всей мощью криптовалютных систем.
                Из минусов:
                — 12 секунд блок — цена глобального консенсуса
                Из плюсов:
                — недоступная ранее надежность,
                — полная автономность распределенных приложений построенных при помощи этих технологий.
                  0
                  Можно забыть про FoundationDB после покупки их Apple?
                    0
                    К сожалению да.
                      +1
                      А какие-то исходники были? Может коммюнити форк сделать? Или хотя бы где можно rpm взять, посмотреть напоследок?
                        +1
                        К сожалению, скаченные когда-то в октябре архивы на пробу уже удалены. Плюсую к вопросу, хотелось бы отыскать зеркало дистрибутивов. Исходников самой базы не было, были исходники SQL-слоя на гитхабе, но сам репозиторий уже удалён.
                          +1
                          Есть последний релиз бд 3.0.7. И есть документ леер, тоже в виде дебиан пакета.
                          +1
                          Ядро БД всегда было закрыто. У меня есть самый свежий релиз в виде .deb, если что. Исходников их лееров (layer) у меня нет. Зато есть тоже .deb файл их нового (так и не релизнутого) леера, который делает вид, что он бд монго.

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое