HighLoad.org – блог о высоких нагрузках
HighLoad.org > В поисках базы данных, которая не была бы отстойной

В поисках базы данных, которая не была бы отстойной
2010-02-18 22:01 my_fess 
Краткое резюме по базам данных, часть из которых отстойные, по крайней мере для моих задач, а другую часть я пока исследую.
SQL
  • MySQL Не хватает INTERSECT и EXCEPT, поддержки массивов. Можно использовать или параллелизм, или полнотекстовый индексы и GIS, но не одновременно.
  • PostgreSQL Есть массивы, параллелизм, полнотекстовые индексы и GIS, но большая часть затеряна в извилистом лабиринте плагинов и нестандартных операторов. Полнотекстовая индексация - отстой.
  • Ingres Ingres сейчас бесплатна (если вам не нужен договор на поддержку). Это хорошая, добротная база данных, но она не может предложить мне ничего нового по сравнению с MySQL + InnoDB.
  • Firebird Похоже, что Firebird, не может мне предложить больше чем MySQL, PostgreSQL, Ingres. Это не значит, что она плохая, но мне она помочь не может.
  • SQL Server Требует Windows, что автоматически порождает недостатки, хотя я и могу достать продукцию Windows и SQL Server enterprise-уровня бесплатно (моя компания участвует в программе Microsoft Bizspark). Есть полнотекстовый индекс, GIS, INTERSECT, EXCEPT, но по-прежнему нет массивов.
  • IBM DB2 Слишком дорого стоит.
  • Oracle Слишком дорого стоит.
  • Progress / OpenEdge Добротная база данных. 4GL - прикольный, но когда я в последний раз смотрел на это в 2006 году я был убит 16-битностью, и к тому же 4GL слишком медленный для чего-нибудь сложного. Также очень дорого стоит и их ценовая модель оказалась провальной. Я бы хотел ее использовать, если бы мог.
NoSQL
  • Redis Хороший набор возможностей. Выглядит очень полезной для небольших систем, но текущая версия является memory-based (она стабильна благодаря снэпшотам и логированию, но база данных должна помещаться в оперативной памяти целиком). Однако разработчики работают над этим. Также стоит подчистить API, в нем есть разные вызовы для одной и той же операции над разными структурами данных.
  • MongoDB Очень хороший набор возможностей. Это база данных документов, но она хранит документы в структуре подобной JSON (которая называется BSON).  Она может вкладывать документы друг в друга.
  • CouchDB Написана на Erlang, что не может не настораживать. Erlang программисты намного больше заботятся о производительности и надежности, чем о создании продукта, который кто-нибудь захочет использовать. В данном случае вместо элегантных query-by-example MongoDB, мне приходится писать map/reduce функции на JavaScript и посылать их на сервер. В какой вселенной это является улучшением SQL? Плюсом CouchDB несомненно является репликация. Минус - то, что это проект Apache. Я не встречал еще проектов Apache, которые бы не были отстойными в каком-то смысле.
  • HBase Хорошо смотрится, если вы имеет дело с миллиардами очень похожих записей (это то, что я делаю на моей дневной работе, но не здесь). Ничего плохого насчет нее, но не подходит мне.
  • Project Voldemort Она используется в Linkedin. Это одна из недавно появившихся масштабируемых key/value баз данных (с автоматическим шардингом и мульти-мастер репликацией). С их собственных слов, это большая, стабильная, отказоустойчивая hash таблица. Это очень полезная вещь, но мне необходимо определять упорядочивание (многократное  упорядочивание для одного и того же набора данных), что невозможно с hash таблицей.
  • Cassandra Это штуковина, основанная на распределенных hash-таблицах от Facebook (ситуация напоминает старые времена, когда каждая серверная компания разрабатывала свой CPU). Ее концепция упорядочивания может быть нечеткой, мне стоит приглядеться получше к ней.
  • JackRabbit Это Java/XML хранилище данных от Apache Foundation. Парни, я имел дело с ActiveMQ. Вы не сможете обмануть меня дважды.
  • Riak Это еще одна key/value/map/reduce штуковина. С их собственных слов:
    "Фаза map" это в сущности просто функция ("F") и аргумент ("A"), т.е. определяется как часть последовательности фаз, составляющих данный map/reduce запрос. Фаза получает поток входов ("I"), каждый из которых состоит из ключа, идентифицирующего Riak объект и необязательный дополнительный элемент данных, сопровождающих этот объект. Когда фаза получает вход, узел, содержащий документ ("D"), соответствующий "I", запускает F(D, A). Смысл в том, что ваша функция может быть запущена над многими данными, но вместо собирания всех данных в одном месте, она будет запускаться где бы ни были размещены данные.
    Понятно? Правильно. Совсем не заинтересован.
  • LightCloud Это распределенное key/value хранилище от Plurk. Плюсы: написано на Python, поддерживает Tokyo Tyrant и/или Redis в качестве бэкенда и "plurk" забавно звучит. Минусы: это просто key/value база данных; похоже она не использует наиболее интересные возможности Tokyo Cabinet или Redis. По крайней мере в есть некоторые update-in-place операции.
  • GT.M GT.M - крокодил. Это не клевета. Крокодилы были современниками динозавров, но когда динозавры вымерли, крокодилы выжили, и они все еще вокруг нас. Это иерархическое key/value хранилище с многообразием механизмов доступа. Оно бесспорно мощное, но выглядит неуклюжим; код MUMPS напоминает мне системы, которые меня нанимали переписывать в 80-х, и Python интерфейс похож не на Python, но на странного потомка Cobol и Pascal.
  • Neo4j Neo4j это база данных, основанная на графах. Я раньше не имел дело с такими. Граф - это общепринятая структура данных для отображения отношений; в то время как реляционные базы данных хорошо моделируют отношения типа родитель-потомок, графы являются естественной моделью для сети друзей (например), где вы можете вернуться туда, откуда начали любым количеством различных путей. Недостаток графов - отсутствие определенного упорядочивания, которое мне необходимо здесь.
Библиотеки
  • BerkeleyDB Это старая, но хорошая вещь. Это встраиваемая, транзакционная база данных. Нет языка запросов, но есть индексы. Одна проблема вот это условие из лицензии:
    "Распространение в любой форме должно сопровождаться информацией, о том, как получить исходный код для программного обеспечения базы данных и любого сопровождающего программного обеспечения, которое использует базу данных.  Исходный код должен быть или включен в дистрибутив или доступен не дороже чем за цену дистрибутива плюс номинальный взнос, и должен быть свободно распространяемым при разумных условиях."
    Любой код, который использует базу данных? Я допускаю, что они имеют ввиду непосредственно встраиваемый/линкуемый код, но это слишком обширно. К тому же это действительно просто библиотека, хоть и очень хорошая; она может служить основой для сервера баз данных, но не им самим.
  • Metakit Metakit это библиотека базы данных, ориентированная на столбцы, с очень хорошим чистым Python интерфейсом. Например, чтобы вывести все сообщения пользователя 'Pixy Misa', вы можете просто написать:
    for post in posts.select(user = 'Pixy Misa'):
      print post.title, post.date
    Проблема в том, что она не масштабируется. Я пробовал использовать ее 4 года назад для Minx, и она сломалась прежде чем база данных достигла текущих размеров. Как и MongoDB - хорошая семантика, но не такая хорошая реализация.
  • Tokyo Cabinet / Tokyo Tyrant / Tokyo Dystopia, VertexDB Tokyo Cabinet это библиотека базы данных похожая на BerkeleyDB, но под беспроблемной LGPL лицензией. Tyrant это легковесный сервер баз данных, основанный на Cabinet. Dystopia это полнотекстовый поисковый движок, основанный на Cabinet. VertexDB это база данных на графах, основанная на Cabinet. Я еще не исследовал их подробно, потому что в стандартный дистрибутив Tokyo Cabinet не входят библиотеки Python (Perl, Ruby, Java и Lua, но нет Python?), но существуют third-party библиотеки.
  • Xapian и Omega Xapian это библиотека полнотекстового поиска, а Omega движок поиска, основанный на Xapian.  Фактически, Xapian больше чем просто поисковый движок; он может искать диапазоны среди строк, чисел и дат, и хранить произвольные документы. Он вполне хорош для поиска, но не предназначен для использования в качестве базы данных.

Автор статьи: Pixy Misa Дата: 7 февраля 2010


комментарии [0]  | комментировать

  © 2010-2018 HIGHLOAD