Структура базы данных для иерархических данных с горизонтальными срезами

Question

В настоящее время мы пытаемся улучшить производительность запросов для нашего сайта, основная иерархическая структура данных имеет 5 уровней, каждый тип имеет около 20 полей.

level1: rarely added, updated infrequently, ~ 100 children
level2: rarely added, updated fairly infrequently, ~ 200 children
level3: added often, updated fairly often, ~ 1-50 children (average ~10)
level4: added often, updated quite often, ~1-50 children (average <10)
level5: added often, updated often (a single item might update once a second)

У нас есть отдельные данныеконвейер, который выполняет все эти обновления и вставки (т. е. у нас есть полный контроль над входящими данными).

Запросы, которые нам нужно сделать по этому поводу:

fetch single items from a level + parents
fetch a slice of items across a level (either by PK, or sometimes filtering criteria)
fetch multiple items from level3 and parts of their children (usually by complex criteria)
fetch level3 and all children

Мы читаем изЭтот источник данных много, как сотни раз в секунду.Все запросы, которые нам нужно выполнить, известны и оптимизированы, а также соответствуют текущей структуре данных.

В настоящее время мы используем запросы MySQL, стоящие за memcached для этого, и просто выполняем дополнительные запросы для получения дочерних элементов./ родители, я думаю, что какая-то база данных на основе дерева или документа могла бы быть более подходящей.

Мой вопрос: каков наилучший способ моделирования этих данных для эффективной производительности чтения?

Answer 1

База данных на основе документов / дерева предназначена для выполнения иерархических запросов.У вас есть какие-то иерархические запросы в вашем дизайне - я не вижу их?Запрос на один уровень вверх и вниз не считается: это простое соединение.Пожалуйста, имейте в виду, что, следуя маршруту «База данных на основе дерева / документа», вы поставите под угрозу свои общие возможности запросов.Подводя итог, просто наймите компетентного специалиста по БД, который проанализирует ваши узкие места в производительности - они обычно устраняются с помощью добавления индекса обыденности.

Answer 2

здесь недостаточно информации, чтобы сказать что-то полезное - вам нужно измерить вещи, посмотреть «объясняет» и т. Д. - но один вариант, выходящий за рамки обычной индексации, - это сегментирование экземплярами уровня 3. это даст вам лучшую производительность при параллельных запросах, которые поражают разные сегменты, на самом простом (отдельных дисках), или вы можете использовать отдельные машины, если хотите использовать больше ресурсов для каждого сегмента.

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

и если ваш объем данных не так велик, то с помощью шардинга вы сможете получить его до ssds ...

Answer 3

Похоже, ваши данные принадлежат базе данных OLAP (On-Line Analytical Processing). То, как вы описываете уровни, срезы и проблемы с производительностью, похоже, пригодно для OLAP. Вероятно, он отлично смоделирован (но не уверен), но вам нужен другой инструмент для повышения производительности.

В настоящее время я управляю такой системой. У нас есть стандартная реляционная база данных для ввода, а затем скопировать соответствующие данные для отчетности на сервер OLAP. Наша компания - это Microsoft SQL Server (входные данные, необработанные данные), Microsoft Analysis Services (предварительные вычисления, а затем сохранение аналитических данных для увеличения скорости), а также сводные таблицы и / или таблицы Microsoft Excel / Access для отчетов.

OLAP-серверы: http://en.wikipedia.org/wiki/Comparison_of_OLAP_Servers

Объединение реляционных и OLAP: http://en.wikipedia.org/wiki/HOLAP

Tableau: http://www.tableausoftware.com/

* Tableau - превосходный продукт, и он может заменить сервер OLAP, если ваши данные не очень большие (даже в этом случае они могут обрабатывать много данных). Он будет делать локальные копии по мере необходимости для улучшения производительности. Я настоятельно советую взглянуть на это.

Если я неправильно понял проблему, с которой вы столкнулись, непременно проигнорируйте этот ответ: \

ОБНОВЛЕНИЕ: После дальнейшего обсуждения, объектная БД также может быть решением. Ваши данные звучат многомерно по своей природе, так или иначе, но я думаю, что разница будет заключаться в том, выполняете ли вы аналитические совокупные вычисления и поиск (SUMs, AVG), или просто храните и извлекаете категориальные или реляционные данные (корзина покупок) предметы или друзья члена семьи).

Информация СУБД: http://en.wikipedia.org/wiki/Object_database

Кэш InterSystem - это одна из известных мне объектных баз данных, которая звучит как более подходящая подгонка в зависимости от того, что вы сказали.

http://www.intersystems.com/cache/

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

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

Примером высокой нормализации может быть использование идентификационных номеров для имени или фамилии человека. Большинство конструкций БД хранят эти имена напрямую и не пытаются уменьшить дублирование, но вы могли бы нормализоваться до точки, где Фамилия и / или Имя имеют свои собственные таблицы (или одну таблицу для хранения Имени и Фамилии) и идентификаторы для каждое уникальное имя.

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

И, конечно же, в целом вы должны иметь соответствующие индексы для ваших данных.

Надеюсь, это поможет.