@cast11 июл 2011 в 12:16

Немного про проектирование баз данных для поисковой машины

3 мин

Комментарии 10

@marapper 11 июл 2011 в 12:57

Кстати, может, добавлять (и обновлять) каждую публикацию внизу полным списком статей по теме, раз собираетесь большой цикл делать?

@cast 11 июл 2011 в 13:00

очень много будет. статей 30 я думаю набежит. а так хоть понятно где искать начало

@marapper 11 июл 2011 в 13:10

Ну тогда да, можно делать такой «дисклаймер» с отсылкой к оглавлению.

@Infanty 11 июл 2011 в 13:07

У меня машинка которая обрабатывает данные имеет много памяти на борту. Из базы данных (Firebird) выгребаю по определённому сайту данные в своё подобие memcached => обработка => пакетное обновление базы данных. В ряде случаев быстрее очистить таблицу и вставить новые данные. Из базы где лежат тексты — только читаем, для всех индексов (в том числе и расчётных) отдельная база. Скорости обработки мне хватает, но по существу как и вы использую базу данных больше как интерфейс к жёсткому диску, чем для применения сложных выборок с объединением (они на таком объёме информации просто неработают).

@cast 11 июл 2011 в 13:09

да, все индексы у меня тоже в отдельных таблицах. А памяти не хватает — кеш базы слов сам по себе от 100 до 200 mb, я уж не говорю про Url. Следующая статья будет про то как я их храню

@cast 11 июл 2011 в 13:10

у меня на машинах от 4Gb памяти, может конечно если поставить 32 то и можно положить хотя бы индексы все в память, но все равно же вырастет. У меня удвоение происходит за месяц активной работы.

@Infanty 11 июл 2011 в 13:13

Нет предела ~~совершенству~~, тут в части случаев вопрос сугубо финансовый, к сожалению ;)

НЛО прилетело и опубликовало эту надпись здесь

@cast 12 июл 2011 в 07:40

Безусловно вы правы

Но, мне кажется, невнимательно прочитали список операций которые надо выполнять и постановку задачи в первой статье цикла…
Не видел ни одной СУБД в состоянии быстро считывать последовательно пару миллиардов записей. Да и таблицы которые бы весили десятки гигабайт и легко обрабатывались тоже редко встретишь в СУБД

Самые частые операции — выборка по ID, и считывание таблицы целиком последовательно. Исходя из этого списки страниц — худшая реализация т.к. надо сначала найти нужную позицию на диске для выборки, в случае же считывания подряд беготня по страницам весьма надоест. В моем случае имеет место жесткая буфферизация чтения, чего в случае с расположенными в непонятном порядке страницами не сделать.

Ну и главное достоинство самописной БД — всегда известно как должно быть устроено приложение чтобы использовать возможности БД на 100% а не на 10%, что я и делаю повсеместно

@kibork 12 июл 2011 в 11:30

То о чем Вы написали это именно то что делает Berkeley DB.
www.aosabook.org/en/bdb.html — можете почитать может может подкинет идей.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий