Создание крупномасштабных систем IR / AI (поиска информации / искусственного интеллекта) с помощью sqlite3 - PullRequest
1 голос
/ 25 ноября 2011

Этот вопрос связан с пригодностью различных механизмов баз данных для исследований в области ИК и ИИ.Два важных вопроса выделены жирным шрифтом ниже.

Я загружаю текстовый корпус объемом 17 гигов в sqlite3, используя python.Позиции заполняют три таблицы с одним шагом нормализации 1 .. * в среднем по 5 записей на строку.У меня нет индексов на столах.Я не собираю операторы вставки вместе, что мне, вероятно, следовало бы иметь, но я вызываю сообщение коммита sqlite только после миллиона строк (таким образом, 3-8 вставок таблицы на строку).Оглядываясь назад, я, вероятно, должен был объединить их в 1000 значений / вставку.Коммит, вероятно, не делает то, что я думал, вероятно, он выполняет внутренние коммиты каждые несколько записей.

Загрузка данных началась с привязки к ЦП, но теперь, когда размер БД составляет 33 гигабайта, кажется, что она связана с вводом-выводом.и открытый текст, и файл базы данных находятся на одном диске.Я предполагаю, что sqlite3 очень консервативен с предварительным заполнением своих страниц и теперь разделяет страницы слева направо и по центру.

В любом случае, я пока остановлюсь на sqlite3, я думаю, преимущество перед базой данных корпоративного уровня заключается в возможности создавать несколько файлов базы данных ad-hoc и размещать их на разных дисках.Традиционно я предполагаю, что большинство людей используют Postgres / Xapian / Sql Server или Oracle для такого рода вещей.

Из опыта Является ли sqlite3 препятствием для создания системы IR / AI или благословением? Я имею в виду, что я даже еще не создал индексы, и данные загружались в течение 14 часов.Если я собираюсь постоянно сталкиваться с такими огромными временами загрузки, я мог бы просто использовать Sql Server для будущего прототипирования. Я знаю, что у Berkeley db также есть интерфейс sqlite3, и он должен обладать характеристиками производительности транзакционной базы данных mvcc, у кого-нибудь есть какой-нибудь опыт применения такого подхода?

edit

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

C ++ может быть просто лучшим языком для загрузки данных (особенно когда речь идет о 340 миллионах строкданных), я ожидаю, что огромное количество бесполезных циклов будет потрачено впустую на копирование и распределение памяти.Поправьте меня, если я ошибаюсь, так как быстрее написать одноразовый код на python.

Ответы [ 3 ]

4 голосов
/ 25 ноября 2011

Просто предложение, но я бы подумал, что с таким большим количеством данных (если у вас нет очень простого шаблона доступа), любая «реальная» БД серьезно превзойдет sqlite3 (хотя протестируйте это ...), (milage зависит от тип двигателя и доступные системные ресурсы - оперативная память, процессор). Кроме того, если вы не используете транзакции, Sqlite будет выполнять транзакции для каждой вставки. Каждая транзакция занимает 2 оборота диска, поэтому ограничением является скорость привода. Попробуйте выполнить одну эпическую транзакцию и посмотрите, сколько времени это займет. Если существует небольшой риск (или опасность потери данных) падения системы в середине импорта данных, вам не о чем беспокоиться, и вам не нужно будет фиксировать каждые 1К строк.

Я понимаю, что это не полностью отвечает на ваш вопрос, но я надеюсь, что это окажется полезным.

1 голос
/ 02 декабря 2011

В какой структуре ваши данные? Возможно, стоит взглянуть на некоторые менее традиционные варианты хранения данных. Это немного старая статья, но она хорошо показывает некоторые другие варианты: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Как следует из информации NoSQL, вы рассматривали возможность параллельного мышления? Если у вас может быть несколько узлов хранилища данных, которые могут принимать записи, вы можете отменить несколько заданий для одновременной вставки данных?

Даже если вы хотите придерживаться RDBS, я бы действительно посоветовал использовать Postgres (или даже MySQL), поскольку они не намного сложнее, чем sqlite, и предоставляют гораздо больше возможностей (включая производительность (зависит от использования)) у вас все еще есть возможность решить, где находится настоящий файл данных. Если возможно, постарайтесь, чтобы данные, которые вы читаете, и файл данных, который вы записываете, также находились на физически отдельных дисках (то есть на совершенно разных шпинделях, а не только на разных логических томах), чтобы головки дисков не тратились и не тратили время. Даже получение данных на отдельном компьютере и подключение их через iSCSI (1 Гбит / с) вполне может оказаться быстрее.

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

0 голосов
/ 04 января 2012

У меня были феноменальные скорости загрузки с BDB, особенно с C ++ во встроенном режиме (т.е. без связи клиент-сервер). На старых машинах (8 лет назад): 50 000 записей в секунду. Попробуй.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...