Sqlite3 вставить тест производительности

Question

В средах высокоуровневой параллельной таблицы блоков SQLite с потерей данных. Я ищу способ улучшить производительность SQLite с высоким параллелизмом без потери данных для запроса вставки. Мое намерение состоит в том, чтобы знать лимит одновременных пользователей для вставки таким образом, чтобы сайт работал (в данном случае 1 вставка для запроса) с «высоким параллелизмом». Чтобы сделать этот тест более простым, пользователи будут отправлять данные для сохранения в базе данных

Посмотрев, как улучшить производительность и воспользоваться советами других пользователей:

• sqlite.org
• sqlite.org / faq.html # q19
• stackoverflow.com / вопросы / 1711631 / как-делать-я-улучшить-на-производительность-на-SQLite
• stackoverflow.com / вопросы / 54998 /, как масштабируемая-это-SQLite

Я решил провести небольшой тест в маленькой амазонке.

Платформа

• версия Linux 2.6.35.14-106.53.amzn1.i686 (mockbuild@build-31003.build) (версия gcc 4.4.5 20110214 (Red Hat 4.4.5-6) ​​(GCC)) # 1 SMP пт 6 января 16 : 20: 23 UTC 2012
• Sqlite 3.6.20
• Lighttpd 1.4.29
• Php 5.3.10

test.php со вставкой sql:

PRAGMA синхронно = ВЫКЛ; НАЧАЛО СДЕЛКИ; INSERT INTO test (data1, date) VALUES ('". $ _ POST [' data1 ']."', Date ()); КОНЕЦ СДЕЛКИ;

Используйте инструмент тестирования Apache HTTP-сервера.

База данных - это файл в файловой системе, но не в оперативной памяти.

ВЫВОД: Тест 1: ab -n 10000 -c 50 -k xxxx.xxx/test.php?data1=fc82bf71a0d5f8a3c2dc868ebe0d6eaa

• Время, затраченное на тесты: 63,637 секунд
• Полные запросы: 10000
• Сбой запросов: 0
• Sqlite вставленных строк: 10050
• Среднее: 159,52 вставки / сГ

Тест2: ab -n 10000 -c 100 -k xxxx.xxx/test.php?data1=fc82bf71a0d5f8a3c2dc868ebe0d6eaa

• Время, затраченное на тесты: 64,221 секунды
• Заполнено запросов: 10000
• Сбой запросов: 0
• Sqlite вставленных строк: 10100
• Среднее: 157,26 вставки / сГ

Тест 3: ab -n 10000 -c 150 -k xxxx.xxx/test.php?data1=fc82bf71a0d5f8a3c2dc868ebe0d6eaa

• Время, затраченное на испытания: 33,338 секунды
• Полные запросы: 10000
• Неудачные запросы: 7095
• (соединение: 0, получение: 0, длина: 7095, исключения: 0)
• SQLITE: 2905 вставленных строк
• Среднее: УТЕРЯННЫЕ ДАННЫЕ !!

TEST4: ab -n 10000 -c 200 -k xxxx.xxx/test.php?data1=fc82bf71a0d5f8a3c2dc868ebe0d6eaa

• Время, затраченное на испытания: 33,705 секунд
• Заполнено запросов: 10000
• Неудачные запросы: 7049
• (соединение: 0, получение: 0, длина: 7049, исключения: 0)
• SQLITE: 2918 вставленных строк
• Среднее значение: УТЕРЯННЫЕ ДАННЫЕ !!

В этой специфической среде мы можем использовать SQLite до 100 одновременно работающих пользователей со средним значением 157,26 insert / sg. Вы учитываете этот результат только для вставки данных.

Из-за моего невежества можно ли предотвратить потерю данных? Можно ли улучшить эту производительность?

Answer 1

Я думаю, что Sqlite3 не следует использовать в вашем случае. Да, sqlite3 - это одна из встроенных баз данных, которая хорошо справляется с параллелизмом, но для хорошего масштабирования и повышения производительности я бы предложил просто использовать базу данных сервер / клиент.

Давайте посмотрим на ваш последний тест, когда вы запускаете запрос 10000 примерно за 30 секунд. Если они распределены одинаково, Sqlite3 не будет разрешено требовать более 3 мс на транзакцию (помните, что sqlite3 допускает только один процесс записи за раз). Давайте посмотрим на документацию sqlite. (http://www.sqlite.org/faq.html)

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

Подводя итог: Просто для блокировки базы данных требуется несколько миллисекунд, не говоря уже о самом обновлении.

Однако механизмы клиент-серверных баз данных (такие как PostgreSQL, MySQL или Oracle) обычно поддерживают более высокий уровень параллелизма и позволяют несколько процессов для записи в одну базу данных одновременно время. Это возможно в базе данных клиент / сервер, потому что есть всегда один хорошо контролируемый серверный процесс, доступный для координации доступ. Если ваше приложение нуждается в большом количестве параллелизма, тогда Вы должны рассмотреть возможность использования базы данных клиент / сервер. Но опыт предполагает, что большинству приложений требуется гораздо меньше параллелизма, чем их дизайнеры представляют.

У вас есть несколько возможностей:

• Измените способ работы вашего приложения. Маловероятно, что вам понадобится столько параллелизма.
• Если вы по-прежнему настаиваете на необходимости параллелизма, хорошей и надежной производительности, переключитесь на базу данных клиент / сервер.
• Примите, что некоторые запросы не выполняются, когда ваша нагрузка достигает пика.