Кэширование данных EAV - XML ​​или NoSQL / MongoDB?

Question

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

OBJECTS              ATTRIBUTES

objId | type         objId | attribute | value
=============        =========================
1     | fruit        1     | color     | green 
2     | fruit        1     | shape     | round
3     | book         2     | color     | red

Я знаю, что некоторые люди ненавидят EAV, но мне нужно иметь возможность произвольно добавлять новые атрибуты объекта, не изменяя схему базы данных, и до сих пор это работает очень хорошо для меня.

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

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

Пока это варианты, которые я придумала ...

1. Столбец базы данных XML: Каждый раз, когда выполняется запись, обновляйте текстовый столбец XML в таблице objects , содержащей все атрибуты объекта. Это бы сработало для быстрого чтения данных, но запрос данных XML, скрытых в таблице базы данных, является грязным

2. XML-файл: Каждый раз, когда выполняется запись, записывайте XML-файл на диск, который содержит каждый объект и его атрибуты. Это дает то преимущество, что я могу затем использовать XQuery для запроса объектов.

3. NoSQL (например, MongoDB): Возможно, мне следовало бы построить систему на базе данных без схемы, такой как MongoDB. Переписывание всего приложения для использования MongoDB заняло бы довольно много времени, но меня поразило, что я могу использовать его в качестве кеша. Так, например, каждый раз, когда данные записываются в хранилище EAV, эквивалентный объект будет обновляться в MongoDB, который затем будет использоваться для чтения и запросов.

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

Мне бы очень хотелось услышать ваши мысли по этому поводу.

Answer 1

Я вижу только два пути, оба они были упомянуты в комментариях.

Во-первых, вы можете действительно перейти на документно-ориентированные БД, такие как Mongo - это подходит в качестве альтернативы EAV. Поскольку это не будет JOINS и другая логика, это будет очень быстро и немного масштабируется. (Так что, возможно, вы сможете избежать использования кэша).

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

Но я хочу обратить наше внимание на будущее этой системы. Что планируется загрузка и масштабирование? Если вы хотите уменьшить нагрузку на систему, я думаю, что лучший способ - это перейти на документно-ориентированную базу данных. Или, если вы хотите получить результат немедленно (кэшировать данные для чтения) - его можно получить с помощью инструмента кэширования, даже [если возможно] на сетевом уровне (например, поддержка nginx memcached из коробки).

Итак, как обычно, вы должны найти баланс между разовыми и постоянными затратами.