Использование реляционной базы данных для получения подробной информации - наилучшая практика

После прочтения шокирующей статьи, написанной Брет Тейлор (соавтором FriendFeed, текущим техническим директором Facebook), Как FriendFeed использует MySQL для хранения данных без схемы, Я начал задаваться вопросом, есть ли лучшие методы для использования СУБД, таких как Oracle, MySQL или PostgreSQL, для хранения и запросов к данным схемы?

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

Ответ 1

thats классическая статья в этом разделе: http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html (Использование MySQL как NoSQL - история превышения 750 000 qps на товарном сервере )

Ответ 2

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

Ответ 3

Я исследовал этот вопрос широко. Весьма тривиально моделировать данные схемы в РСУБД, используя таблицу "свойств" (по существу, используя пары ключ/значение). Жесткая часть - это индексирование и запрос к вашим вещам. (По сути, вся сложность, с которой столкнулась Friendfeed, сосредоточена вокруг этой проблемы.)

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

Хорошее решение этой проблемы основано на использовании Partial Indexes (aka. Filtered Indexes).

Ответ 4

Вы не найдете многого в этой теме, потому что большинство людей строят одноцелевые решения. Их решения разработаны для удовлетворения одной потребности очень хорошо. Базы данных NoSQL сильно страдают от создания этих хранилищ данных единого назначения, но вы платите за отсутствие гибкости и некоторых встроенных элементов управления и функций безопасности РСУБД.

Ответ 5

Инженеры Quora используют MySQL как хранилище данных вместо NoSQL, таких как Cassandra, MongoDB, CouchDB и т.д.. Они разделяют данные на уровне приложений, что означает, что они делят данные только при необходимости, сохраняют данные на одной машине, если это возможно, и используют хэш первичной ключ для разделения больших наборов данных в нескольких базах данных. Разделение данных на уровне приложений работает таким образом, что данные, удовлетворяющие одному набору критериев, "передаются" одной базе данных, а данные, не отвечающие этим критериям (или, возможно, другой набор критериев), могут быть отправлены в другую базу данных