Бюро переводов. Раньше мы решали свои задачи с помощью программ полнотекстового поиска вроде dtsearch. Потом перешли на самописное добро, vb.net. Всё работает , но медленно.
Наша типичная задачка:
- есть таблица базы данных с двумя столбцами. В одном столбце - слово (тип string). В другом столбце- ID файла содержащего это слово и т.п.

Запросом создаем табличку частотности слов, типа "слово- в скольких строках БД встречается".

Если обрабатывать лишь 4000 страниц текста (порядка 250 слов на страницу)- это уже дает порядка 1 000 000 слов (т.е. записей) - и такое уже не мгновенно работает.

А нам хотелось бы обрабатывать хотя бы 40 000 страниц - а это уже 10 млн записей и реально небыстро происходит. (Вообще то у нас под сотни тысяч страниц текстов, но об анализе таких объемов под 100 млн строк в БД , пока даже не задумывались..)

Еще что: НЕ ТРЕБУЕТСЯ работа по сети (всё сейчас происходит на отдельном компьютере), работает один пользователь, может быть сколько угодно много библиотек, сложное развертывание, долгое создание индексов и пр

Вопрос. Какая организация хранения слов даст максимальную производительность на таких задачках- выборках слов с их обсчетом и пр? (Похоже все кто делает full text search используют проприетарные технологии хранения слов- от google До DtSearch.. но нам не хотелось бы так усложнять..)

Кто на таких задачах быстрее - SQLite, JET, Firebird, MS SQL Express и т.п.?

Кстати, 10 млн слов - это всего лишь порядка 200 Мб (если считать макс длину слова 20 байт)- пр таких базах-крошках переход к in memory database ничего не даст, да?

Интересует исключительно скорость выборки. А при прочих равных услвоиях - удобство интеграции с программами сделанными в .NET.

Dimitry Sibiryakov,

Поясню.
я- переводчик, не программист. Чтобы нанимать человека со знанием интересующих нас технологий работы с текстом (морфологизация, токенизация и пр) - надо хотя бы в общих чертах понимать перспективы задачи. А может там такое потребуется железо, что это будет просто нерентабельным?)

Возможно , мы НЕ ТАК работаем с текстами, как следовало бы. Ок.

Но ваш ответ очень типичен для рашкинских программеров).
Мне, например, приходится много работать с американскими юристами- к ним обращаешься- помогут даже с общими вопросами - ибо у них есть ВИДЕНИЕ и пр. А к местным обратиться- отвечают примерно как вы).

Типа вы нам ТехЗадание поставьте и пр. лепет.

Dimitry Sibiryakov,



Анекдот был такой:
- Если на американском форуме задать вопрос- ответят решением.
- Если на израильском форуме задать вопрос- ответят вопросом.
- Если на российском форуме задать вопрос- тебе объяснят , что ты идиот)

Вы прям таки иллюсстрация.

Dimitry Sibiryakov,

я исхожу исключительно из собственного опыта).

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

kdv,

Я же писал в посте- "создаем табличку частотности слов,"

то есть - имеем десятки тысяч файлов в формате plain text. Это наши (и предоставленные заказчиками) переводы.

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

вася-IDфайл1
петя-IDфайл1
...
вася-IDфайл2
маша-IDфайл2
...

стало (слово "Вася" встречается 2 раза, "петя"- 1 раз)
вася- 2
петя- 1
---------------------------------------------------------------


Кроме того. При анализе текстов мы отбрасывам "стоп-слова" (предлоги "на", "под", междометия "ух" и пр). Еще и стеммером приводим слова к единой форме.


Поэтому, с учетом того, что сырые данные нами обрабатываются (подсчет числа слов- самый простой пример обработки)- то на выходе, после обработки, таблички частотности слов редко содержат более 20 000 слов.

То есть ДО обработки- миллион слов, выковыренных из txt файлов.
После обработки- редко более 20 000 слов (и то там много фамилий, географических названий и пр)- ничего аномального для русского языка у нас нет.

"PS вы всерьёз полагаете, что ваша "задача" "выходит за рамки примитива" ?"


А что есть "примитив"?) в моем понимании, это когда есть более-менее устраивающий заказчика алгоритм.

Далее, идут задачи уровнем ниже- копаться в деталях кода. Ассемблер для тех кто ходит в очках с толстыми линзами, в общем.

А в моей задаче нетривиально сделать оценку быстродействия - как время выполнения запроса бубудет меняться с ростом числа слов и пр?

Нетривиально для меня, например. Но раз вы все молчите- значит и для вас.

Ибо если человек не может "на пальцах" что то прикинуть, пояснить где узкое место- он не специалист. А так- постсовковый ходячий интерфейс к информации в MSDN, залитой туда белыми людьми)

Dimitry Sibiryakov,

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


- Отлично! Интересует именно МИНИМИЗАЦИЯ времени выполнения данной "разовой операции". Ибо:


Сегодня мы работаем с одним набором текстов от одного заказчика, завтра - с совсем другим набором.

Но каждый раз перед началом перевода делается некая "переводческая аналитика". //Это скучная наша кухня. Если "на пальцах"- смотрим насколько тексты пересекаются с тем, что мы пранее переводили, доля аббревиатур-чисел в текстах и пр//

В эту "аналитику" входит и то , что мы сейчас делаем запросами к БД- создание итз выковыренных из текстов слов "табличек показывающих с какой частотой встречается слово в данной группе текстов" .

Для каждой группы текстов- СВОЯ табличка частотности. То есть, ранее выполненная работа с ИНЫМИ текстами НИКАК нам не помогает для обсчета НОВОЙ кучи текстов.

Вот и интересуемся- какая БД для конкретного набора текстов создаст "табличку частотности" з аминимальнео время.

PS Можно, конечно, и просто программой пройтись по сырым текстовым файлам- и прямо во время прохода по сырцам сделать такую табличку.
Но такое не годится. Нам нужно много запросов- и хотелось бы все таки делать это максимально стандартными способами- запросами к НЕКОЙ БД, а не писать уникальный код для каждой выборки по словам(.

РосгоснанораспилтрестlemmaИбо если человек не может "на пальцах" что то прикинуть, пояснить где узкое место- он не специалист. А так- постсовковый ходячий интерфейс к информации в MSDN, залитой туда белыми людьми )

Индусы - они... Как бы это... Не совсем белые.


- Ну поправим- белые и не совсчем белые, но отбеленные немного)

Andrey Sribnyak,

"Подобная задача сейчас крутится на ms sql без проблем вообще
вот первых 20 по числу упоминаний:"

- Вы делаете упор на "Без проблем".
А для меня ваш ответ не очень информативен, ибо как я писал:

1) Есть набор текстов
2) Надо сделать табличку частотности
3) Работа с КАКОЙ БД МИНИМИЗИРУЕТ (!!!!) время создания таблички подобной той что вы указали.

Ну сделали вы табличку. Так мы и сами можем.
Какая связь вашего ответа с моим постом? Я в нем спрашивал о минимизации времени ее первичного создания.

Ggg_old,

"lemma, вчем проблема? Вы весьма подробно описали, как решать вашу задачу. Мне не очень понятно,в чем тормоза."

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

А) Я не программист. Сам могу делать поверхностные вещи, скажем в vb.net. У меня есть более IT-продвинутые сотрудники, но они, увы, исполнители. Поставить цель, написать техзадание, тем более ОБОСНОВАТЬ использование архитектуры и пр- они не могут.

Б) Мой бюджет ограничен- навороченного специалиста я в штат нанять не могу, да и незачем, вроде- работа то проектная.

В) Наверное, идеалом было бы обращение к консалтерам. Но даже с ними как-то не хочется начинать общение с нуля.

Г) Для нас ключевой момент - программа должна максимально быстро выполнять запросы о которых написано выше.
//Можно упомянуть OLAP - на моем дилетантском уровне, при таком подходе из "совсем сырых" цифровых данных делаются некие срезы. Промежуточные расчеты. Используя их, аналитик может делать достаточно сложные запросы - но это будет быстро (!) ибо строятся они не через обращение к исходным данным а к результатам промежуточной обработки. НО УВЫ, ничего похожего на OLAP при работе с текстовыми данными вроде нет///
Поэтому, вроде, тут первичный вопрос о том, в каком виде хранить данные. А именно- выковыренные из исходных текстов слова и пр. (работать нам нужно именно на уровне СЛОВ. Имеющиеся средства полнотекстового поиска большинство наших задач не решают).

Д) Я нигде не смог найти тестов сравнения производительности разных БД. Например, сколько времени занимает создание индекса или некий запрос для 1 млн строк . И т.п.
Плюс сейчас много информации о каких то экзотических для меня вещах типа in- memory database, или базы данных с хранением по столбцам ( Column-oriented DBMS). Все они говорят , что рвут конкурентов).
Плюс все пишут что у Google и пр поисковиков данные хранятся в проприетарном формате.

Е) В общем- избыток информации. Я немного запутался). Упрощаю вопрос.
Есть текстовый файл, plain text. он состоит из строк, в каждой строке- ровно ОДНО слово (макс длина слова 20 байт). Сколько строк? обычно до 10 000 000, но не хотелось бы как то ограничивать себя числом строк..

Нужно сделать табличку частотности. А именно:
Был текстовый файл
-------------
вася
петя
вася
вася
петя
.............
--------------
Стала табличка частотности, сколько раз встречается слово:
вася- 3 раза
петя - 2 раза
---------------------
Вопрос. В какой базе данных такая табличка делается быстрее всего? (то есть нам нужно сначала текстовый файл запихать в некую БД. В лоб по текст-файлам считать не годится)