#sql #database #database-design #architecture #nosql
#sql #База данных #проектирование базы данных #архитектура #nosql
Вопрос:
У нас есть дизайн таблицы, который состоит из 10,000,000 записей и 200,000 столбцов.
Столбцы представляют собой смесь:
- Двоичные флаги.
- Целые числа.
Запросы должны выполнять and / or операции над 1-100 столбцами одновременно и должны выполняться менее 0.1 чем за секунды, возвращая только проекцию / подмножество каждой сопоставленной строки.
10 В день добавляется около новых столбцов.
1,000 В день добавляется около новых строк.
Соединений нет.
Какая СУБД лучше всего подходит для этого?
Причина такого подхода:
Столбцы представляют собой материализованные индексы из пользовательских запросов: вот почему новые столбцы добавляются каждый день (по мере того, как все больше пользователей задают свои собственные запросы). Другим вариантом было бы не использовать материализованные представления и заставить запросы пользователя выполнять соединения. Проблема здесь в том, что запросы могут принимать любую форму, и в совокупности будет большое количество самых разных планов выполнения для каждого запроса … поскольку пользователь определяет запрос, невозможно оптимизировать традиционную базу данных SQL с использованием индексов, нормализованных таблиц и т. Д.
Комментарии:
1. Звучит как один из худших проектов за всю историю. Можете ли вы сказать нам, зачем вам нужно 200 000 столбцов ?!?
2. Отложив в сторону, можете ли вы сами создавать объединения достаточно быстро… Зачем вам нужно помещать все в одну таблицу? Разве вы не можете материализовать каждый запрос отдельно?
3. Да, это хороший вариант. Это означает, что вместо этого у нас будет таблица для каждого типа запроса (если я вас правильно понимаю). На данный момент я не могу сказать, есть ли у нас больше типов запросов или больше столбцов… но вполне вероятно, что при таком подходе у нас будет ~ 100 000 таблиц.
4. разве это не вопрос для администраторов баз данных? Я думаю, что ваш вопрос лучше всего подходит.
Ответ №1:
Во-первых, я бы предложил измерять специальные соединения и проводить дальнейшую оптимизацию только в том случае, если вы обнаружите, что производительность недостаточна. Я понимаю, что может быть сложно измерить все возможные запросы, но вы можете охватить наиболее распространенные / репрезентативные случаи, и если они работают достаточно хорошо, просто остановитесь на этом. С хорошей индексацией можно многое сделать!
Во-вторых, и только если это оправдывают приведенные выше измерения, создайте новое отдельное материализованное представление для каждого специального запроса.
- Некоторые базы данных смогут автоматически поддерживать такие представления для вас 1, поэтому, если «базовые» данные изменятся, соответствующие результаты будут автоматически добавлены или удалены из материализованного представления (точно так же, как они были бы из «живого» результата запроса).
- Другие базы данных могут допускать периодическое обновление 2.
Однако имейте в виду: поддержание материализованных представлений не является бесплатным, и их тысячи (особенно если они постоянно обновляются, а не периодически обновляются) определенно повлияют на производительность вставки / обновления / удаления базовых данных!
1 Например, индексированные представления SQL Server.
2 Например, Oracle Materialized views, хотя похоже, что 12c также может сделать что-то близкое к немедленному обновлению SQL Server.
Ответ №2:
Оставляя в стороне, почему вы хотите использовать 1000 столбцов, вы можете посмотреть ниже базы данных, которые поддерживают неограниченное количество столбцов
Ссылки: https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems