Есть большой CSV файл, и его надо просмотривать в web с сортировкой по различным столбцам и простеникими условиями. Во что бы его такое перегнать для этого? Файл 30 MB, 200 тыщ записей, в SQLite perl'ом перегоняется около 20 секунд, что медленно (т.е. через while(<>) он читается порядка пары секунд - хотелось бы чтобы с базой данных было сравнимо). Настройки такие:PRAGMA journal_mode = NONE
PRAGMA synchronous = OFF
PRAGMA locking_mode = EXCLUSIVE
PRAGMA temp_store = MEMORY
PRAGMA cache_size = 20000В mysql также 20 сек, но правда без настроек, да и mysql вообще говоря жирно.
В SQLite можно еще какие-нибудь прагмы включить, чтобы быстрее было? Никакие целостности базы, понятно, не волнуют. Можно из коммандной строки его перегнать (т.е. без перла с dbi, что вносит свои тормоза)? Может другие БД для этого есть?
>[оверквотинг удален]
>PRAGMA temp_store = MEMORY
>PRAGMA cache_size = 20000
>
>В mysql также 20 сек, но правда без настроек, да и mysql
>вообще говоря жирно.
>
>В SQLite можно еще какие-нибудь прагмы включить, чтобы быстрее было? Никакие целостности
>базы, понятно, не волнуют. Можно из коммандной строки его перегнать (т.е.
>без перла с dbi, что вносит свои тормоза)? Может другие БД
>для этого есть?а зачем тебе его вообще быстро загонять?
>а зачем тебе его вообще быстро загонять?
>>его надо просмотривать в web с сортировкой по различным столбцам и простенькими условиями
>>а зачем тебе его вообще быстро загонять?
>>>его надо просмотривать в web с сортировкой по различным столбцам и простенькими условиямия понял это, вопрос был ЗАЧЕМ БЫСТРО?
>я понял это, вопрос был ЗАЧЕМ БЫСТРО?аа. Ну была идея при первом запросе смотреть на дату модификации файлов и если исходный файл изменился пересоздавать базу. Ну повисит один запрос в неделю секунд 5, подумаешь. А 20 это уже не кошерно, тем более что будет больше.
Если перегонять заранее, то SQLite подходит практически идеально, но мне казалось что если не заморачиваться журналами и транзакциями а просто лить рекорды в базу, а потом быстро создать индексы, должно быть быстро. Вопрос в том кто это умеет, желательно консольной утилитой, ибо perl по строкам читает это долго.
>>ЗАЧЕМ БЫСТРО?
>аа. Ну была идея при первом запросе смотреть на дату модификации файлов и если исходный файл изменился пересоздавать базу.Ежели измения недольшие (например, добавление 1-2-20-100... строк), то сделай инкрементальное обновление базы по дифу исходного файла. Когда и если заработает -- будет быстро (для небольших изменений).
>один запрос
>в неделю секунд 5, подумаешь. А 20 это уже не кошерно,По запросу, обнаружевшему изменение отдавать старую страницу и запускать обновление асинхронно. Следующий запрос, прришедший ч/з 20+ секунд - получит новые данные.
Новую базу создавать "в сторонке" и вбрасывать на место рабочей по готовности, чтоб промежуточных состояний клиент не видел.
>Если перегонять заранее, то SQLite подходит практически идеально,
Ну, перегоняй _асинхронно_. Запуск "перегонного аппарата" - опросом по крону и/или, как выше, из клиентскмх запросов.
>если не заморачиваться журналами и транзакциями а просто
Перечитайте пожалуйста тред.>Ежели измения недольшие (например, добавление 1-2-20-100... строк), то сделай инкрементальное обновление базы
>по дифу исходного файла. Когда и если заработает -- будет быстро
>(для небольших изменений).Изменений нет вообще.
>>один запрос
>>в неделю секунд 5, подумаешь. А 20 это уже не кошерно,
>По запросу, обнаружевшему изменение отдавать старую страницу и запускать обновление асинхронно. Следующий
>запрос, прришедший ч/з 20+ секунд - получит новые данные.Нет, старую страницу отдавать нельзя.
Беркли, возможно, с индексами для нескольких полей. Плюс ещё базу можно создавать в tmpfs, а потом готовую переложить куда надо (если вообще надо). Не обещаю, что выйдет намного быстрее, но более быстрый вариант вряд ли придумаешь.
Хотя вот ещё. Если размеры базы и оперативки позволяют загружать её целиком, то можно читать прямо из csv или юзать сериализацию объектов, a-la pickle в питоне, не знаю как это в перле делается.
>Беркли, возможно, с индексами для нескольких полей. Плюс ещё базу можно создавать
>в tmpfs, а потом готовую переложить куда надо (если вообще надо).
>Не обещаю, что выйдет намного быстрее, но более быстрый вариант вряд
>ли придумаешь.bdb попробую, забыл про нее совсем. tmpfs и память ен подходят.
Несколько тестов показали
dbi без транзакций - слишком долго чтобы дождатся
dbi с транзакциями, но без prepare+execute 0m19.059s
без dbi через open FH,'|/usr/bin/sqlite3 test.db', используя транзакции 0m6.831s
dbi с транзакциями и prepare+execute 0m5.943sВсе это без каких-либо настроек sqlite3. Используя вышеизложенное, телепатирую - вы забыли про prepare+execute :)
Э-э-э, а как это еще по-вашему можно сделать, кроме как через prepare/execute? Имено ими с сделаоно.
Покажите код и его замер на вашей машине.
>Файл 30 MB, 200 тыщ записей, в SQLite perl'ом перегоняется около 20 секунд,
>что медленно (т.е. через while(<>) он читается порядка пары секунд - хотелось
>бы чтобы с базой данных было сравнимо). Настройки такие:Опять - "админящие программеры" атакуютЪ :)
Автор - запусти sqlite3, затем натяпай .h<Enter> - читай внимательно и фффтыкай на опции .mode csv & .import file table
Никаких заметь перлов и по-строчный импортов :)))PS: Всё как обычно укра^W написано до нас :)
Я так понимаю "программирующий админ" в жизни своей не видел csv файла сложнее чем ряд чисел разделенных запятой, про роль всяких там кавычек и слешей даже не догадывается. Надо заметить что .import придерживается такого же примитива и единственный задаваемый параметр это delimiter. Рекомендую глянуть синтаксис load data infile в mysql для сравнения.
И это не говоря уже про то, что по различным причинам запуск клиентского бинаря может быть нежелателен/невозможен.P.S. .import почти в два раза быстрее перла или текстового файла с insert.
>Я так понимаю "программирующий админ" в жизни своей не видел csv файла
>сложнее чем ряд чисел разделенных запятой, про роль всяких там кавычек
>и слешей даже не догадывается.Автор люто налюбился с экспортом из Excel лет 10 назад :) Таких сумасшедших Csv-шек больше ни за каким другим софтом не замечал ... а делает их уйма софта, до сих пор!
>Надо заметить что .import придерживается такого же примитива и единственный задаваемый параметр это delimiter.
Чего может оказаться вполне достаточно. Равно как может и не оказаться.
>И это не говоря уже про то, что по различным причинам запуск
>клиентского бинаря может быть нежелателен/невозможен.А запуск такого же клиентского перл-скрипта - будет кошерным? Чудеса!(С) :-)
>P.S. .import почти в два раза быстрее перла или текстового файла с insert.
Ну дык.(С)
>Автор - запусти sqlite3, затем натяпай .h<Enter> - читай внимательно и фффтыкай на опции .mode csv & .import file table
>Никаких заметь перлов и по-строчный импортов :)))Про это я и спрашивал, спасибо.