Бюро переводов. Раньше мы решали свои задачи с помощью программ полнотекстового поиска вроде 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 раза
---------------------
Вопрос. В какой базе данных такая табличка делается быстрее всего? (то есть нам нужно сначала текстовый файл запихать в некую БД. В лоб по текст-файлам считать не годится)

.ЛП,
"Судя по описанию задачи, сравнивать СУБД тут вообще ни к чему. "

Как это ни к чему, если единственное что меня интересует, КАКАЯ именно БД максимально быстро выполнит конкретную операцию?

я тут еще попытался расшифровать- для тех кто выше за деревьями не видит леса)
http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=907965&msg=11862364

Andrey Sribnyak,



я тут еще попытался расшифровать- для тех кто выше за деревьями не видит леса)
http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=907965&msg=11862364

Dimitry Sibiryakov,

/нам нужно сначала текстовый файл запихать в некую БД. В лоб по текст-файлам считать не годится/

"Что мешает? Задача-то (как описана) не для СУБД. Вам в key-value область. "
- Спасибо. не знал про key value. Оказывается, это сейчас модно -
http://dotsid.wordpress.com/category/key-value/



"Т.е. сначала вы
по файлу строите эту табличку в памяти, "

- Так не годится же ваш продход. ).
Я же писал желаемую последовательность шагов:
А) имеющиеся текст-файлы разбираем по словам
Б) слова запихиваем в НЕКУЮ БД
В) Эту базу потом ковыряем запросами, в том числе типа частотности. Задача- указать бьазу данных максимально быстро позволяющую сделать табличку частотности.

То есть мы хотим работать со словами запиханными в базу. А вы предлагаете в очередной раз сделать табличку частотности ВНЕ базы данных, а потмо всё запихать в БД.
Это варварский подход). Делать надо сатндартными средствами все. А не так- для каждой задачи свой код.
Еще предложите табличку средствами Ассемблера создать)


"а потом уже можете заливать её в любую СУБД. На
Lua, например, эта задача решается в десять строчек."
- вот поясните, чсто дает в даном случае обращение к языку LUA по которому мало информации, специалистов? Что , все это на с++ сделать нельзя?
или вы просто слова новые любите?)

Dimitry Sibiryakov,

"Потому что ты как баран упёрся в своё решение этой задачи "посчитать частоты вхождения
слов средствами СУБД". Эта задача быстрее и проще решается ВНЕ СУБД."

- конечно. на асемблере такое особенно быстро решается).
Ты, постсовковый кодер, в состоянии ли понять, что если изначально я пишу "НАДО ДЕЛАТЬ ТАБЛИЧКУ В НЕКОЙ БАЗЕ ДАННЫХ" - то это так и надо понимать.

Интересует же в КАКОЙ (!) базе она делается за минимальное время.

Dimitry Sibiryakov,

"1) разбираем файл по словам."
- да.это мы умеем. RegExp-ами

"2) Каждое слово запихиваем в БД "
- да.это мы умеем. пихали в mdb и в SQL Express. Сейчас вопрос тут вот задаем "а в КАКУЮ базу оптимальнее".

"(хотя это и глупость - запихивать надо только уникальные
слова, "
- Вы опять отвекаетесь от темы. Мы же не обсуждаем архитектуру Базы.
Мы тут обсуждаем в КАКОЙ именно базе максимально быстро делается некий простой запрос- на частотность.
Но если уж хотите обсуждать кухню, то в каждом файле слово стемиируется (приводится к единой форме), слову присваивается уникальный номер внутри файла, и в базу запихивается слово и номера где оно встретилось.
Для чего номера слова нужны? Чтоб сниппеты выковыривать из начального текста.
Нашли незнакомео слово типа "быдлокодер" и зная его номер в файле выковыриваем окружающий его текст
"... обычно в РФ быдлокодером зовут тех, кто понятия не имеет о бизнес-логике.."


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

3) Запихиваем в БД между делом посчитанные частоты
4) Базу ковыряем запросами хоть до посинения.
"между делом "- ага. Это ключевое слово для РФ. Тут такие как вы всё делают "между делом". Попробуйте понять, - мы хотим получить оптимизацию (быстродействие) в рамках стандартного подхода (работа с sql запросами в некой БД). А вы как обычно делают местные криворукие кулибины предлагаете изобретать велосипед)


Именно ТАК это сделал бы любой программист.
- так вы программист невысокого уровня, судя по темам ваших постов в этом форуме. вы пытаетесь говорить о том, что выше вашей планки.)

Ну а переводчики могут идти
лесом в американские форумы.
- и пойдем!)

CodeGenerator,

"Кстати, делал не так давно систему по БД автозапчастей. Там в общей сложности значительно больше 500 000 000 записей."

-звучит интригующе! еще бы понять откуда столько записей- у них там вебкамера на складе что ль снимок в базу каждую секундуц сбрасывют?!

"Самые сложные выборки данных отрабатывали за 0,1-0,5 секунды, учитывая что сервером был одноядерный Sempron 1.6 2Gb операти"
- смотрите. Я говорю об операциях суммирования. Берется слово и считается сколько раз встретилось. То есть, чтобы ТАКОЕ проделать - базе тупо приходится перебирать ВСЕ свои строки. Тут индексы и пр НИКАК не помогут.

В моем случае , все таки, полагаю, перебор с суммированием 500 млн записей за СЕКУНДУ - это пока не для десктопов)

Dimitry Sibiryakov,

посмотрел ваш профиль. названий 10- этого вполне достаточно.
вы узкоспециализированный программист. такие тоже нужны.

но на стадии определения архитектуры вы мало полезны, полагаю. ничего личного.

CodeGenerator,

поправлю свой ответ- "базе тупо приходится перебирать ВСЕ свои строки. Тут индексы и пр НИКАК не помогут."

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

Dimitry Sibiryakov,

"и славно над вами поиздевается"
- если придет такой же дурачк как ты, то поиздеваться не поучится)

ты постоянно уходишь от ответа на простйо вопрос - у какой бд для конкретной выборки максимальная скорость к особенностям реализации)

ps кстати, заинтриговал.
как вообще могут над кем то издеваться люди, если в РФ вроде вообще нормальных специалистов нет? все у кого руки не кривые - уехали, не?)

Dimitry Sibiryakov,

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

Люди либо гадят (бросают "пять сигареток" мимо урны) , либо нет.
Программа либо сделана качественно, либо коряво- таким как ты, кодером из села Верхние Залупки)

видал я тексты таких клованов). сплошной код без комментариев- верный признак того, что чел из РФ писал))

Andrey Sribnyak,

"Еще раз спрошу... зачем каждый раз пересчитывать ,сколько это слово уже раз встречалось????
Почему нельзя <<<каждый раз>>>, когда вы добавляете это слово просто увеличивать счетчик на единицу(в отдельной таблице, где эти слова в единственном экземпляре)? Кто вам мешает???"

---------------
Что хочу я:
- загнав слова в БД делать некие специфические запросы. Интересует исключительно скорость выполнения для разных баз. При том что В МОМЕНТ ЗАБИВАНИЯ ИНФО в базу никаких специальных дополнительных действий (построение таблиц чсастотности)- не производится. Грубо говоря- загнали лсова в базу. Сделали индекс. И пинаем базу запросами

ЧТо предлагаете вы:
- параллельно таблице "исходной сырой информации" делать "на лету некие дополнительные объекты.
А именно- через счетчик строить некий ДОПОЛНИТЕЛЬНЫЙ объект. Словарь его назовем или табличу вхождений.

Понятно, что если подобное раз пострноить (при загрузке данных в БД)- все летать будет.

По сути, вы предлагает заранее создать интересующий нас объект. И все будет быстро. Так мы это умеем. Но хотим НИЧЕГО не создавать заранее. А таблички генерировать тупо запросом.


Мы же не банк, где есть четкая рутина. Где можно прописать рабочие места, запросы и пр- и софт может работать долго без сильных изменений.


У нас задачи-то разные и характер запросов разный. Локализовать софт и перевести тома документов- совсем разные запросы понадобятся. Каждый раз что то специально выстраивать- неразумно.


Для нас оптимально- что тот кто анализирует тексты , создает запросы в наглядной и простой среде вроде ms access. А вопрос в том- какие хранилища этими запросами обрабатываются. ЧТоб была макс скорость.

Dimitry Sibiryakov,

"Тогда скажи мне, милое дитя: к какой единой форме у вас там приведётся слово "день"?"


- ты, недокодер, опять путаешь вопрос скорости и детали реализации совсем иного блока.


Для НАШИХ целей НЕ ПРИНЦИПИАЛЬНО к какой форме стеммер приведет слово.

Ибо. У нас , условно говоря, есть два объекта:
А) паттерн (шаблон, маска ). Это набор неких слов
Б) Анализируемый текст.

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

так что в какую форму преобразует конкретное слово сьеммер- нам обычно не важно. Такова жизнь. Хотя иногда важно. Но зачем от обсуждения минимальной скорости выполнения запроса ты перевел разговор на стемминг?

Ты написал про value-key и оракл. спасибо. остальное можешь выбросить в печку.)

Dimitry Sibiryakov,

"Но вас же интересует запрос подсчёта частоты вхождения слова в текст. Было бы странно если
бы на текст "косил косой косой косой" запрос на слово "коса" выдал нуль..."

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

мы пытаемся что то выковыривать по кусочку. Те задачи которые было очевидно как решать- давно у переводчиков решены. А есть задачи, где все упирается тупо в ресурсы.

раз было предложение в- течение ДНЯ (!) распознать порядка 10 000 сканов документов (до кучи, все- с низким разрешением)- сделать анализ текстов и озвучить примерную цифру.

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

Ведь можно рассуждать и так:
А) алгоритмы ускорения поиска -различные индексы -давно придуманы
Б) врдя ли у какой то БД есть свой, уникальный алгоритм
В) если объем файла невелик (скажем до 1 Гб) - всё загоняется в память и там тупо считается. У разных баз- примерно одинаково????

Г) если все ТАК обстоит, получается, скорость выполлнения запроса зависит исключительно от мощности процессора (и их числа, если задачу можно распаралеллить)?????

и никак не зависит от скорости доступа к диску иль иных деталей?