Подбор СУБД

И вложенные запросы, и транзакции тоже порадовали...

Но! после 3.23 стало платным😡

:D

Dim2,

Стоп! А разве 4.x не бесплатно?.. Где-то, в каком-то дистрибутиве нашла или скачала - не помню. Или вы винды в виду имеете? :(

Free Public License до 3.23.19

далее GPL и commercial

http://www.mysql.com/company/legal/licensing/mypl.html

Dim2,

The MySQL database server is available under the MySQL AB "dual licensing" model. Under this model, users may choose to use MySQL products under the free software/open source GNU General Public License (commonly known as the "GPL") or under a commercial license.

Или CNU-сные продукты имеют ограничения?

MySQL 4.1 Downloads

http://dev.mysql.com/get/Downloads/MySQL-4.1/mysql-standard-4.1.8-unknown-freebsd4.7-i386.tar.gz/from/pick

господа, а кто вообще сказал, что в крупном поиске(а тут речь идет именно об этом, как я понимаю) речь идет о готовой СУБД?

имхо, писать надо самому. причем видимо придеться писать сво. собственную мини СУБД, ввод/вывод на диск уж точно...

а инстурменты:

c++, asm, perl

Sherman,

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

конечно можно, скажем статистику.

Очень неплохая СУБД - PostgreSQL. Имеет все то, что только еще обещают в mysql 5.x.

насчет mysql можно посмотреть примеры использования:

http://www.mysql.com/it-resources/case-studies/

вот одна цитатата оттуда: "Los Alamos National Labs Relies on MySQL to Scale with 7 Terabytes of Data."

Тема вроде давно отзвучала , но все же.

Я конечно не знаком с разработчиком "совы" , я сам разработчик другого украинского сервера , "сова" меня опережает по посетителям, но не намного. Суть не в этом . Пользователи так же недовольны.

После определенных измышлений я пришел к выводу что SQL базы не годятся для поисковых машин и вот из каких соображений. Дело в том что индексы SQL баз состоят из листов , в которых есть значение и ссылка на запись в таблице. При ничтожных записях , таких как например KEYW(INT) DOC(INT) POINTS (int) , размер индекса превышает размер таблицы, для оптимизации SQL запроса таких индексов может быть три , в итоге индексы могут превысить саму запись в несколько раз. Вы индексируете 1 мб , а получаете 4 мб . Для публики дожно быть понятно что я здесь описал процесс очень грубо, если хотите узнать как помучайтесь сами ;-). Отсюда следует расход памяти и скорость. Кроме того , SQL базы оставляют "дыры" в индексах, они нужны чтоб быть готовыми вставить запись. Что для поискового сервера не совсем требуется.

Во вторых я пришел к выводу , что процесс должен состоять из двух частей , первая - это сбор и коллекционирование информации (тут может применяться SQL) , не путать с простой работой паука, и компилирование собранной информации в структуру пригодную для поиска. В процессе компиляции часть информации может быть отброшена , например если слово "окно" посторяется 100000 раз , то поверьте оно врядли вам пригодиться в таком количестве. При выдаче обычно отдается первых 200 результатов , и даже если предположить что возможен mix с другими словами , все равно его столько не нужно. А сколько нужно - будет зависеть от вашей политики.

Далее я заметил что яндекс меняет выдачи версиями баз. Т.е. коллекционирует и в определенные дни происходит замена одной базы на другую. Целиком.

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

Что касается mysql и применения в непоисковых системах, то тут у меня имеется опыт до 4 Гб , все работает очень быстро.

не совсем понял логику автора, если большой индекс, больше положенного по расчётам - так это вина архитектора БД и/или программиста.

а вы думаете при написании свой БД не возникает проблем ?!

Простой пример , таблица из одного поля INT ( 4 байта) , индекс построенный по этому значению будет занимать ( 4 + 4(размер указателя) ) * 3/2 (заполняемость) или на 1 значение - 12 байт, что ~ в 3 раза превысит оригинальный размер таблицы. И это не вина разработчика , а особенность хранения данных .

По mysql прочтите раздел "Estimating Query Performance".

Однозначно это сложнее , только есть техническая задача и ее решение , иначе в песочницу .