Производительность вставки базы данных

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

Вставляемые данные очень просты, например:

CREATE TABLE [dbo].[price](
    [product_code] [char](15) NULL,
    [market_code] [char](10) NULL,
    [currency] [nchar](6) NULL,
    [timestamp] [datetime] NULL,
    [value] [float] NULL,
    [price_type] [char](4) NULL
) ON [PRIMARY]

Microsoft SQL Server:

Общее время тестирования: 32 секунды. 3,099 цены в секунду.

Сервер MySQL:

Общее время тестирования: 18 секунд. 5 349 цен в секунду.

Сервер MongoDB:

Общее время тестирования: 3 секунды. 25 555 цен в секунду.

Цель этого тестирования - просто получить небольшое представление о том, какую "сырую производительность" можно ожидать от систем в нижней части. При реализации решения мы, конечно, будем делать буферизацию, объемные вставки и т.д.

Мы только заботимся о скорости вставки, так как запрос выполняется "офлайн" позже.

Есть ли у кого-нибудь предложения для других баз данных, которые могут поместиться? Сегодня вечером я буду использовать HDF5 и MonetDB. Его необходимо иметь доступ нескольких клиентов.

Спасибо за любые предложения!

ОБНОВЛЕНО:

Извините, но я сделал большое изменение моего вопроса перед тем, как поместить его, и, похоже, я оставил версии сервера и некоторые детали оборудования. Все тесты проводились на 8-ядерном сервере с 12 ГБ оперативной памяти с Windows 2008 x64.

Microsoft SQL Server 2008 Enterprise x64. MySQL 5.1.44 работает как таблица InnoDB. MongoDB 1.2.4 x64

Текущий тест представляет собой простой цикл вставки строк в БД с реальными историческими данными из NASDAQ, скомпилированными в CSV файл, уже импортированный в память. Код был в С# NET4 x64.

Серверы MS SQL и MySQL были настроены на идеальные настройки, в то время как MongoDB был настроен только по умолчанию. Таблицы SQL настроены без индексов, поскольку цель БД проста в качестве промежуточной площадки, прежде чем переносится в основную систему анализа.

Многие предлагали Bulk inserts, однако это сложный способ сделать это, поскольку у нас есть несколько клиентов, которые нажимают одиночные тики в DB независимо от живых потоков. Чтобы разрешить такие методы, нам нужно было бы расширить слой перед БД, помимо того, что у нас есть шанс проверить прямо сейчас. Однако я предполагаю, что для окончательной архитектуры нужно будет сделать что-то, поскольку числа, которые мы получаем от всего, кроме MongoDB, недостаточно для обработки количества необходимых входных данных.

ОБНОВЛЕНИЕ 2: SSD-накопители действительно хороши для этого, и мы сами это используем. Однако конечный продукт будет установлен на нескольких разных клиентах, которые все предоставляют свое железо. И получение серверов из ИТ-отдела с помощью SSD все еще сложно...: (

ОБНОВЛЕНИЕ 3:

Я попробовал подход BulkCopy. Производительность для того же цикла, что и другие, но сначала в DataTable, а затем BulkInsert в SQL Server привела к следующему:

Microsoft SQL Server (Bulk):

Общее время тестирования: 2 секунды. 39401 цен в секунду.

Ответ 1

Я могу только прокомментировать sql-сервер, но есть некоторые вещи, которые можно попробовать:

командный пакет (т.е. сделать несколько INSERT одним ударом по db)
объемная вставка (через SqlBulkCopy)

либо должны внести существенные улучшения в однострочные вставки (последние самые быстрые)

Ответ 2

Цель этого тестирования - просто немного узнать о том, что вид "сырой производительности" может быть ожидаемый от систем в нижней части. При фактическом внедрении решения мы, конечно, будем буферизировать, навалом вставки и т.д.

Вы могли бы по крайней мере поделиться деталями своих тестов. Опуская такую важную информацию, как то, что MySQL engine вы пытаетесь, непростительно. И "сырая производительность" неспаренной вставки в базе данных на основе буфера (например, SQL Server или InnoDB) не имеет смысла, это как измерение "необработанной производительности" Ferrari на первой передаче, а затем публикация того "он идет только до 50 миль в час".

Но в любом случае, если вы хотите масштабируемую оптимизированную для записи базу данных, посмотрите Cassandra из Apache Incubation. Слух о слухах говорит, что Twitter скоро примет его.

Ответ 3

Как это сравнить с простое ведение журнала в плоский файл в файловой системе? Если запрос выполняется позже, я не уверен, почему вы передаете данные в реляционную базу данных в это время. Есть ли необходимость в транзакциях или множественном доступе к базе данных на этом этапе записи?

Ответ 4

Если вы хотите работать только с вставкой, вы можете получить больше от mysql, используя Archive engine и INSERT DELAYED.

В противном случае попробуйте любой из двигателей KV с локальным хранением: BDB, QDBM, Tokyo Cabinet и т.д.

Ответ 5

Существует множество способов оптимизации производительности, и разные базы данных обрабатывают данные очень разные. SQL Server, например, защищает ваши данные, он должен быть уверен, что данные действительны и на диске, прежде чем он позволит вам знать, что вставка была успешной. MySQL и MongoDB делают это, поэтому они могут быть быстрее. Так что ты ищешь? RDBMS или какое-то хранилище, где вы можете позволить себе потерять некоторые данные?

Ответ 6

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

Ответ 7

Вы тестировали несколько экземпляров приложений, подключенных к серверу базы данных, и вставляли данные одновременно или только одно приложение?

Я думаю, вы должны тестировать несколько экземпляров, особенно для массовой вставки, и посмотреть, какая конфигурация работает для вас. Различные режимы изоляции транзакций могут значительно повлиять на производительность для одновременного доступа (особенно для доступа к записи). SQL Server, например, я обнаружил, что режим изоляции ниже, чем ReadCommitted, должен использоваться для высококонкурентной среды или вы найдете много случаев таймаута. Разумеется, это следует использовать, когда риск грязного чтения не вызывает беспокойства (что соответствует вашему делу, судя по вашему описанию).

PS: Простите меня, если я заявляю здесь очевидное.

Ответ 8

Я бы тоже рассмотрел возможность выбора версии 5.5.5. Ребята из Oracle сделали значительные улучшения в этой версии, особенно для выпуска Windows. До 1 500 процентов прироста производительности для операций чтения/записи и до 500 процентов прироста для Read Only. Вы можете сослаться на эту ссылку для получения дополнительной информации:

http://www.mysql.com/news-and-events/generate-article.php?id=2010_04