База данных против доступа Fstream

Question

У меня есть (локальная) база данных (MySQL 5.1 в Ubuntu 10.10) с примерно 15000 таблицами, каждая из которых содержит в среднем ~ 1 000 000 строк.Каждая таблица имеет 6 ДВОЙНЫХ столбцов.Механизм хранения - MyISAM.У меня есть приложение C ++, которое загружает данные по одной таблице за раз и выполняет некоторые вычисления.Я извлекаю данные из базы данных простым способом: SELECT * FROM table ORDER BY timestamp;(отметка времени - это первый столбец (DOUBLE), помеченный как UNIQUE). Большая часть времени уходит на загрузку и выборку.Для загрузки и извлечения всех строк в одной таблице требуется ~ 15 секунд (пробовал с собственным C API, C ++ Connector и MySQL Query Browser).Когда я загружаю тот же набор данных с диска (текстовый файл), используя fstream, та же самая операция занимает всего ~ 4 с.

Возможно ли для MySQL или любой другой базы данных (SQLite?) Приблизиться к этому значению?Хотя у меня есть в основном простые SELECTS и INSERTS (+ один простой JOIN), мне нравится идея базы данных, потому что управлять большими наборами данных несколько проще, поэтому я буду придерживаться ее даже за счет некоторой потери производительности, но 15/4на таблицу слишком много, учитывая количество таблиц.Я был бы хорошо с 6 / 4s, хотя ...

Спасибо.Petr

Answer 1

Последовательное сканирование всех записей - не самый убедительный вариант использования реляционной базы данных, но я определенно рекомендую вам также протестировать SQLite.Обычно считается, что это высокопроизводительная замена для пользовательских файловых операций ввода / вывода.

Answer 2

Чтение файла - это не то же самое, что использование SQL для извлечения данных. Чтение файла требует только чтения с диска и помещения его в память. Вот и все.

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

Затем, когда это будет сделано, он анализирует файл и извлекает данные в соответствии с запросом. Есть также небольшие накладные расходы, потому что связь между клиентом и сервером осуществляется через. розетки.

Итак, между доступом к файлам и тем, что делает MySQL, существует огромная разница. С MySQL вы получаете много, много больше, за счет скорости.

Зачем вам в любом случае 15 000 столов? Я чувствую недостаток в вашем дизайне, если вам нужно так много столов ...

Answer 3

Во-первых, вы достаточно плохо используете базу данных, имея 15 000 таблиц. Это не то, как эти базы данных предназначены для работы.

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

Вы используете базу данных SQL для чего-то, для чего она не предназначена - и при этом злоупотребляете ею. Я не ожидал бы, что это сделает очень хорошую работу.

Answer 4

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

Я видел приложение (используемое на крупном сайте социальных сетей), которое по очень специфической потребности заменило кластер из 8 больших серверов MySQL оптимизированным кодом C ++, работающим на одном блейде, с использованием ~ 5-10% , (Он рассчитал социальный график и кратчайшие пути между пользователями).

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