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

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

я тут еще попытался расшифровать- для тех кто выше за деревьями не видит леса)
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 Гб) - всё загоняется в память и там тупо считается. У разных баз- примерно одинаково????

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

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