Начинаю новый проект.
Предполагаемый объем данных:
документов - ~100,000,000
место на диске - 15-20 Gb (в txt формате)
+
Online Search Engine
На P4 — 2800Gh+4Gb

Всю жизнь хранил данные в txt.
Есть опыт с DB = (84 Mln docs ~10Gb). Но update делаю раз в 6 мес.

Сейчас придется делать update в реальном времени => присматриваюсь к MySQL,
Собираюсь использовать MySQL++.

Поискать поискал, но не нашёл точных ответов.
Помогите дать оценку:

1. Какой будет ~объём DB MySQL.
2. Какой будет ~объём индекса.
3. Скорость update (doc/sec) Возможный входящий поток до 50 doc/sec
4. Скорость поиска по 1-2-3-... ключевым словам (микро - милли - sec - ... - часы)
   средствами MySQL.
5. Скорость выборки документа по ID (микро - милли - sec)

Если есть опыт с бОльшими или меньшими объёмами — отпишите пожалуйста.
Вдруг удасться интерполировать.








.

Практика — критерий истины... Почему бы самому не проверить? Это ведь не сложно.

Здравствуйте, SimplyJoe, Вы писали:

SJ>Практика — критерий истины... Почему бы самому не проверить? Это ведь не сложно.
Простота хуже воровства... (р.нар.поговорка) Проверено временем.

А так....
Спасибо, конечно.







.

Здравствуйте, VMin, Вы писали:

VM>Начинаю новый проект.
VM>Предполагаемый объем данных:
VM>документов - ~100,000,000
VM>место на диске - 15-20 Gb (в txt формате)

Что-то я вот эти цифры не осознаю. 200 байт на документ?
А место под служебные данные

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Здравствуйте, VMin, Вы писали:

VM>>Начинаю новый проект.
VM>>Предполагаемый объем данных:
VM>>документов - ~100,000,000
VM>>место на диске - 15-20 Gb (в txt формате)

КД>Что-то я вот эти цифры не осознаю. 200 байт на документ?
Фамиля, имя, адрес — ~ 50-100 байт
и много чисел по 1-2-3-4-5-... байт.
У меня есть такая привычка хранить text+birary микс в txt файле.
Хотя Вы правы!
Вохможно будет раза в два больше.

КД>А место под служебные данные

А что такое служебные данные ?
В чём отличие от просто данных?
Или это внутренние данные MySQL?
Если это так, то я и интересуюсь: насколько распухнет дата при переходе от txt к MySQL.









.

когда вечь идёт о каком либо проекте, всегда задумываются о том, чем этот проект будет через 1-2 года.

В случаи с документами необходимо задуматся о контекстном поиске -- это раз.
(в MySQL он оч. плохо представлен)
Нормальный контекстный поиск есть под Oracle (Yandex) и под Postgres.

В отличии от всех остальных баз данных MySQL имеет множество форматов хранения данных (MyISAM, InnoDB, etc). У каждого есть свои + и — -- это два.

О размере индекса и размере базы сложно говорить, если не знать зарание структуру базы -- это три.

Я ещё раз. повторюсь: БАЗАМ ДАННЫХ (....) сколько строчек -- им важен обьём одной и интенсивность их добавления (сумарный размер за транзакцию в единицу времени) -- это 4

Практика:
MySQL база не плохая.
Был опыт хранения 10 лямов строчек по ~100байт, работало шустро, а вот со сложной выборкой при таких обьёмах были проблемы.

Здравствуйте, VMin, Вы писали:

VM>На P4 — 2800Gh+4Gb
VM>Всю жизнь хранил данные в txt.
VM>Есть опыт с DB = (84 Mln docs ~10Gb). Но update делаю раз в 6 мес.

VM>Сейчас придется делать update в реальном времени => присматриваюсь к MySQL,
VM>Собираюсь использовать MySQL++.

VM>Поискать поискал, но не нашёл точных ответов.
VM>Помогите дать оценку:
VM>

VM>1. Какой будет ~объём DB MySQL.
VM>2. Какой будет ~объём индекса.
VM>3. Скорость update (doc/sec) Возможный входящий поток до 50 doc/sec
VM>4. Скорость поиска по 1-2-3-... ключевым словам (микро - милли - sec - ... - часы)
VM>   средствами MySQL.
VM>5. Скорость выборки документа по ID (микро - милли - sec) 
VM>

Сначало в общем, при таком объеме данный MySQL на любой машине ляжет. Мой тебе совет ставить или MSSQL или Oracle.
1. объем данных будет зависить от самого объема данных этих самых документов =)
2. Индекс если на оракле делать все качественно и тонка все настроить то не соизмеримый.
3. все зависит от самого механизма обновления =)
4. это можно самоому провертиь опять все от грамотных индексов зависит
6. см. пункт 4