Комментарии 10
Кстати, может, добавлять (и обновлять) каждую публикацию внизу полным списком статей по теме, раз собираетесь большой цикл делать?
У меня машинка которая обрабатывает данные имеет много памяти на борту. Из базы данных (Firebird) выгребаю по определённому сайту данные в своё подобие memcached => обработка => пакетное обновление базы данных. В ряде случаев быстрее очистить таблицу и вставить новые данные. Из базы где лежат тексты — только читаем, для всех индексов (в том числе и расчётных) отдельная база. Скорости обработки мне хватает, но по существу как и вы использую базу данных больше как интерфейс к жёсткому диску, чем для применения сложных выборок с объединением (они на таком объёме информации просто неработают).
НЛО прилетело и опубликовало эту надпись здесь
Безусловно вы правы
Но, мне кажется, невнимательно прочитали список операций которые надо выполнять и постановку задачи в первой статье цикла…
Не видел ни одной СУБД в состоянии быстро считывать последовательно пару миллиардов записей. Да и таблицы которые бы весили десятки гигабайт и легко обрабатывались тоже редко встретишь в СУБД
Самые частые операции — выборка по ID, и считывание таблицы целиком последовательно. Исходя из этого списки страниц — худшая реализация т.к. надо сначала найти нужную позицию на диске для выборки, в случае же считывания подряд беготня по страницам весьма надоест. В моем случае имеет место жесткая буфферизация чтения, чего в случае с расположенными в непонятном порядке страницами не сделать.
Ну и главное достоинство самописной БД — всегда известно как должно быть устроено приложение чтобы использовать возможности БД на 100% а не на 10%, что я и делаю повсеместно
Но, мне кажется, невнимательно прочитали список операций которые надо выполнять и постановку задачи в первой статье цикла…
Не видел ни одной СУБД в состоянии быстро считывать последовательно пару миллиардов записей. Да и таблицы которые бы весили десятки гигабайт и легко обрабатывались тоже редко встретишь в СУБД
Самые частые операции — выборка по ID, и считывание таблицы целиком последовательно. Исходя из этого списки страниц — худшая реализация т.к. надо сначала найти нужную позицию на диске для выборки, в случае же считывания подряд беготня по страницам весьма надоест. В моем случае имеет место жесткая буфферизация чтения, чего в случае с расположенными в непонятном порядке страницами не сделать.
Ну и главное достоинство самописной БД — всегда известно как должно быть устроено приложение чтобы использовать возможности БД на 100% а не на 10%, что я и делаю повсеместно
То о чем Вы написали это именно то что делает Berkeley DB.
www.aosabook.org/en/bdb.html — можете почитать может может подкинет идей.
www.aosabook.org/en/bdb.html — можете почитать может может подкинет идей.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Немного про проектирование баз данных для поисковой машины