База данных для сверхбыстрых [закрытых] запросов
7 ответов
Если вы хотите выполнять специальные запросы для составления отчетов или анализа, то вам, вероятно, лучше использовать что-то, что будет хорошо играть с готовыми инструментами для составления отчетов. Иначе Вас, скорее всего, будут постоянно тянуть за собой, чтобы записать небольшие программы-отчеты для запроса данных. Это удар по базам данных типа NoSQL, но это может быть проблемой, а может и не быть, в зависимости от ваших обстоятельств.
300 Гб не должны выходить за рамки возможностей современных платформ СУБД, даже MS SQL Server. Некоторые другие варианты для больших запросов к СУБД такого типа:
Посмотрите, можно ли использовать куб SSAS и объединения для уменьшения проблем с производительностью ваших запросов. Оптимизация, основанная на использовании, может обеспечить достаточную производительность без необходимости получения другой системы СУБД. SSAS также можно использовать в конфигурациях без совместного доступа, позволяя вам распределять запросы по кластерам относительно дешевых серверов с прямым подключением дисков. Посмотрите на ProClarity для внешнего интерфейса, если вы все-таки пойдете этим путем.
Sybase IQ - это платформа СУБД, использующая базовую структуру данных, оптимизированную для формирования отчетов по запросам. Ее преимущество заключается в том, что она прекрасно работает с разумным набором обычных инструментов отчетности. Существует несколько других систем этого типа, таких как Red Brick, Teradata или Greenplum (которая использует модифицированную версию PostgreSQL). Главный удар по этим системам заключается в том, что они не совсем массовые и могут быть довольно дорогими.
У Microsoft в разработке находится версия SQL Server с нулевым доступом, которую вы, возможно, сможете использовать. Однако они привязали его к сторонним производителям аппаратного обеспечения, так что вы можете получить его только с помощью специализированного (и, следовательно, дорогого) аппаратного обеспечения.
Ищите возможности для построения мартов данных с агрегированными данными, чтобы уменьшить объемы некоторых запросов.
Посмотрите на настройку своего аппаратного обеспечения. Массивы SAS с прямым подключением и RAID-контроллеры могут довольно быстро проходить через потоковые входы/выходы, используемые в табличном сканировании. Если вы разбиваете ваши таблицы на большое количество зеркалируемых пар, вы можете получить очень быструю потоковую передачу данных, легко насыщающую каналы SAS.
На практике, если вы хотите получить 10-20 ГБ/с от вашей подсистемы ввода/вывода, то вы можете сделать это, не прибегая к действительно экзотическому оборудованию.
Я не уверен, что согласен с тем, что традиционные базы данных SQL не могут обрабатывать эти объемы , Я могу запрашивать гораздо большие наборы данных в те сроки, но он был разработан специально для выполнения такого рода работы и размещен на подходящем оборудовании, в частности, подсистеме ввода-вывода, которая предназначена для обработки больших запросов данных.
Правильно настроенный SQL-сервер должен уметь обрабатывать данные в террабайтах без проблем с производительностью. У меня есть несколько друзей, которые управляют базами данных SQl Server, размер которых не вызывает проблем с производительностью.
Ваша проблема может заключаться в одной или нескольких из них:
- Неадекватные спецификации сервера
- Отсутствие хорошей разбитости
- Плохая индексация
- Плохая структура базы данных
- Плохая структура запросов, в том числе с использованием инструменты типа LINQ, которые могут писать плохо работающий код для базы данных такого размера.
Безусловно, это НЕ способность SQL-сервера обрабатывать такие нагрузки. Если у вас есть база данных такого размера, вам нужно нанять профессионального dba с опытом оптимизации больших систем.
Это действительно зависит от того, какие пункты у вас есть в WHERE и какой вид проекции вам нужен для ваших данных.
Возможно, этого будет достаточно, чтобы создать соответствующий индекс для вашей таблицы.
Кроме того, даже наличие оптимальной структуры данных бесполезно, если вам нужно читать 100 ГБ на запрос, так как это тоже займет свое время.
Насколько я понимаю, традиционные СУБД основаны на строках, что оптимизирует скорость вставки. Но оптимизация скорости извлечения лучше всего достигается с помощью системы хранения на основе столбцов.
См. СУБД с ориентацией на столбцы для более подробного объяснения, чем я мог бы дать
Предоставленные ответы верны. Тем не менее, если вы намерены использовать ffuts, то вы можете преобразовать ваш номер в последовательность, используя sprintf сначала. Примерно так:
#include <stdio.h>
#include <stdint.h>
int main(int argc, char **argv){
uint32_t counter = 4;
char buffer[16] = {0};
FILE * fptOut = 0;
/* ... code to open your file goes here ... */
sprintf(buffer, "%d", counter);
fputs(buffer, fptOut);
return 0;
}
В стандартное затмение этого не существует. Единственное, что можно сделать, это добавить закладку и извлечь все закладки в представлении закладок. Для обоих действий можно определить комбинации клавиш (дважды нажмите Ctrl + Shift + L и выполните фильтрацию по закладке).
Однако, вы можете найти плагин, который делает то, что вы хотите (например, http://www.etc.to/eclipse_bookmarks_plugin )
-121--4460191- NoSQL , как вы могли прочитать, не является реляционной базой данных.
Это база данных, в которой хранятся пары ключ-значение, через которые можно перейти с помощью собственного API .
Это означает, что необходимо определить физическую структуру данных самостоятельно, а также выполнить оптимизацию кода.
Я довольно устарел в этом, но несколько лет назад я участвовал в проекте BerkeleyDB , посвященном чуть менее, но все еще высоким объемам данных (около 100Gb ).
Это было совершенно нормально для наших потребностей.
Обратите внимание, что запросы могут быть оптимизированы, хотя это может показаться вам очевидным. Не могли бы вы опубликовать используемый здесь запрос?
Я ожидаю, что «обычная» база данных может делать то, что вы хотите, при условии, что вы правильно структурируете свои данные для выполняемых запросов.
Вы можете обнаружить, что для создания респектабельных отчетов вам необходимо суммировать данные по мере их создания (или загрузки, преобразования и т. Д.) И составлять отчет по сводным данным.
Скорость SELECT не связана (в большинстве случаев напрямую) с количеством условий в предложении WHERE (обычно), но связана с планом объяснения и количеством проверенных строк. Есть инструменты, которые проанализируют это за вас.
В конечном счете, при 300 Гбайт (что не ТАК большой) вам, вероятно, потребуется хранить некоторые данные на диске (= медленно) хотя бы некоторое время, поэтому вы захотите начать сокращать количество требуемых операций ввода-вывода. Сокращение операций ввода-вывода может означать создание покрывающих индексов, сводных таблиц и копий данных с разными кластеризованными индексами. Это делает ваш 300G больше, но кого это волнует.
Операции ввода-вывода - король :)
Очевидно, что выполнение этих задач очень дорого с точки зрения времени разработчика, поэтому вам следует начать с добавления большого количества оборудования в проблему и пытаться исправить ее с помощью программного обеспечения только тогда, когда этого становится недостаточно. . Большое количество ОЗУ - это начало (но он не сможет хранить> 10-20% вашего набора данных за раз при текущих экономически эффективных уровнях). Даже твердотельные накопители не так дороги в наши дни.