Базы данных следующего поколения

Я бы сказал, что это база данных следующего поколения, а не SQL следующего поколения.

SQL - это язык для запросов и управления реляционными базами данных. SQL продиктован международным стандартом. Хотя стандарт пересматривается, кажется, что он всегда работает в рамках парадигмы реляционной базы данных.

Вот несколько новых технологий хранения данных, которые сейчас привлекают внимание:

• CouchDB - это нереляционная база данных. Они называют это базой данных, ориентированной на документы.
• Amazon SimpleDB также является нереляционной базой данных, доступ к которой осуществляется распределенным образом. через веб-службу. У Amazon также есть распределенное хранилище ключей и значений под названием Dynamo, которое поддерживает некоторые из его сервисов S3.
• Dynomite и Kai - решения с открытым исходным кодом, вдохновленные Amazon Dynamo.
• BigTable - это проприетарное решение для хранения данных, используемое Google, и реализованы с использованием их технологии файловой системы Google. Фреймворк Google MapReduce использует BigTable.
• Hadoop - это технология с открытым исходным кодом, созданная на основе Google MapReduce и обслуживающая аналогичная потребность, чтобы распределить работу очень больших хранилищ данных.
• Scalaris - это распределенное транзакционное хранилище ключей / значений. Также не реляционный и не использует SQL. Это исследовательский проект Института Цузе в Берлине, Германия.
• RDF - это стандарт для хранения семантических данных, в котором данные и метаданные взаимозаменяемы. У него есть собственный язык запросов SPARQL, внешне похожий на SQL, но на самом деле совершенно другой.
• Vertica - это хорошо масштабируемая аналитическая база данных, ориентированная на столбцы, предназначенная для распределенной (грид-сети) архитектура. Он утверждает, что он реляционный и совместимый с SQL. Его можно использовать через Amazon Elastic Compute Cloud.
• Greenplum - это СУБД для крупномасштабных хранилищ данных, в которой реализованы как MapReduce, так и SQL.
• XML - это вообще не СУБД, это формат обмена. Но некоторые продукты СУБД работают с данными в формате XML.
• ODBMS или объектные базы данных предназначены для управления сложными данными. Похоже, что в массовом сегменте нет доминирующих продуктов ODBMS, возможно, из-за отсутствия стандартизации. Стандартный SQL постепенно приобретает некоторые функции объектно-ориентированного программирования (например, расширяемые типы данных и таблицы).
• Drizzle - это реляционная база данных, большая часть кода которой заимствована из MySQL. Он включает в себя различные архитектурные изменения, предназначенные для управления данными в масштабируемой системной архитектуре «облачных вычислений». Предположительно, он продолжит использовать стандартный SQL с некоторыми улучшениями MySQL.
• Cassandra - это хорошо масштабируемый, в конечном итоге согласованный, распределенный, структурированный ключ. value store, разработанная в Facebook одним из авторов Amazon Dynamo и внесенная в проект Apache.
• Project Voldemort - это нереляционная распределенная система хранения ключей и значений. Используется на LinkedIn.com
• Заслуживает упоминания Berkeley DB. слишком. Это не «следующее поколение», потому что оно восходит к началу 1990-х годов. Это популярное хранилище ключей и значений, которое легко встраивать в различные приложения. В настоящее время технология принадлежит Oracle Corp.

Также см. Эту замечательную статью Ричарда Джонса: "Anti-RDBMS: список распределенных хранилищ ключей и значений." Он более подробно описывает некоторые из этих технологий.

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

Год за годом исследователи придумывают новые способы управления данными, чтобы удовлетворить особые требования: либо требования для обработки взаимосвязей данных, которые не вписываются в реляционную модель, либо требования крупномасштабного объема или скорости, требующие обработки данных. на распределенных наборах серверов, а не на центральных серверах баз данных.

Несмотря на то, что эти передовые технологии позволяют решить специализированную проблему, для которой они были разработаны, реляционные базы данных по-прежнему являются хорошим универсальным решением для большинства бизнес-потребностей. SQL никуда не денется.

Я написал статью в журнале php | Architect об инновациях в нереляционных базах данных и моделировании данных в реляционных и нереляционных базах данных. http://www.phparch.com/magazine/2010-2/september/ < / а>

Мне пока не хватает графических баз данных в ответах. Граф или сеть объектов широко используются в программировании, а также могут быть полезны в базах данных. Он может эффективно обрабатывать полуструктурированную и взаимосвязанную информацию. Среди областей, в которых графические базы данных вызывают большой интерес, - семантическая сеть и биоинформатика. Был упомянут RDF, и на самом деле это язык, представляющий граф. Вот несколько указателей на то, что происходит в области базы данных графа:

• Графики - лучшая абстракция базы данных
• Graphd, серверная часть Freebase
• Графический движок базы данных Neo4j с открытым исходным кодом
• AllegroGraph RDFstore
• слой абстракции Graphdb для биоинформатики
• Graphdb за механизмом рекомендаций Directed Edge

Я участвую в проекте Neo4j, который написан на Java, но также имеет привязку к Python, Ruby и Scala. Некоторые используют его с Clojure или Groovy / Grails. Также развивается GUI-инструмент.

Возможно, это не лучшее место для ответа на этот вопрос, но я хотел бы поделиться этой таксономией мира noSQL, созданной Стивом Йеном (ее можно найти на http://de.slideshare.net/northscale/nosqloakland-200911021)

1. ключ-значение-кеш

   • memcached
   • перекэшированный
   • согласованность
   • in nispan
   • экстремальный масштаб
   • jbosscache
   • скорость
   • терракока

2. хранилище ключей-значений

   • 
keyspace
   • fl являются
   • без схемы
   • RAMCloud

3. постоянное хранилище ключей и значений

   • dynamo
   • Волдеморт
   • Диномит
   • SubRecord
   • MongoDb
   • Dovetaildb

4. заказанный-ключ-значение-магазин

   • tokyo
tyrant
   • светлое облако
   • NMDB
   • люкс
   • memcachedb
   • актер

5. сервер структур данных

   • redis


6. хранилище кортежей

   • gigaspaces
   • согласовывать
   • Apacheriver

7. база данных объектов

   • ZopeDB
   • db4o
   • Мелководье

8. хранилище документов

   • CouchDB
   • Монго
   • Зайчик
   • XML-базы данных
   • ThruDB
   • CloudKit
   • Perservere
   • РиакБашо
   • Скаларис

9. магазин с широкими столбцами

   • BigTable
   • Hbase
   • Кассандра
   • Гипертаблица
   • КАЙ
   • OpenNep

Чтобы узнать, какие академические исследования проводятся в области баз данных следующего поколения, взгляните на это: http://www.thethirdmanifesto.com/

Что касается языка SQL как правильной реализации реляционной модели, я цитирую википедию: «SQL, который изначально был продвинут в качестве стандартного языка для реляционных баз данных, в нескольких местах отличается от реляционной модели. Текущий стандарт ISO SQL не упоминать реляционную модель или использовать реляционные термины или концепции. Однако можно создать базу данных, соответствующую реляционной модели, используя SQL, если не используются определенные функции SQL ».

http://en.wikipedia.org/wiki/Relational_model (упоминается в разделе «SQL и реляционная модель »28 марта 2010 г.

Не хочу быть педантичным, но я хотел бы отметить, что по крайней мере CouchDB не основан на SQL. И я надеюсь, что SQL следующего поколения сделает SQL намного менее ... неустойчивым и неинтуитивным.

Существуют специальные базы данных для XML, такие как MarkLogic и Berkeley XMLDB. Они могут индексировать xml-документы, и их можно запрашивать с помощью XQuery. Я ожидаю базы данных JSON, возможно, они уже существуют. Погуглил, но не нашел.

SQL существует с начала 1970-х, поэтому я не думаю, что он скоро исчезнет.

Возможно, «новый (-ish) sql» будет oql (см. http://en.wikipedia.org/wiki/ODBMS)

Я слышал также о NimbusDB от Джима Старки

Джим Старки - человек, который «создает» Interbase

кто работает на Vulcan (вилка Firebird)

и кто был у истоков создания Falcon для MySQL