что выбрать для хранения нескольких тысяч записей в несколько килобайт.

[SiDChik]

что выбрать для зранения нескольких тысяч записей в несколько килобайт.

Собственно Subj. Такая ситуация, рассмотрим на примере gmail. Скажем мы имеем 5000 активных пользователь в течении часа.... И сайт должен хранить информацию, допустим 2-3 документа размеров в 1 kb.. Всё это редактируется on-line редактором... так что за час будет до сотни тысяч сохранений.... Всего записей получается для активных пользователей 15 тысяч...

Так вот, основной вопрос такой, в чём лучше хранить. В отдельных файлах или БД.

Если файлы, то постоянная нагрузка на жётский диск.

БД чем больше таблица, тем тормоза в выполнении.

Храниться у меня будет что то типа векторного изображения. Или некоторые объекты. т.е. свой формат.... Вот не могу выбрать что мне нужно, т.е. чем реализовать чтобы оптимизировать работу.

Надеюсь на понимание.

П.С. Поможет ли использование других БД? Хранить придеться порядка двухсот тысяч записей, может даже чуть больше. В идеале пятьсот тысяч.

 

[Tor]

пятьсот тысяч

для большинства БД - это семечки

з.ы. хранить бинарные данные в базе - моветон

 

[SiDChik]

на локальной машине MySql глючит при поиске по базе с 200 000 записями.... (это я писал бот антивикторины ) храниться будет всё в формате текста... т.е. как текстовые файлы.... размером в 1-2 тысячи символов...

Есть ещё у кого мнение?

Tor, спасибо

 

[AmdY]

200 000 тысяч файлов, тоже не фонтан. Я б сказал даже хуже.

 

[Фанат]

есть мнение, что на локальной машине MySql глючила не из-за 200 000 записей...

 

[AmdY]

базы данных созданы для хранения БОЛЬШИХ обьёмов информации.

 

[SiDChik]

вполне возможно... в любом случаи понятно, что копать надо в сторону БД, спасибо всем.

 

[kruglov]

AmdY

базы данных созданы для хранения БОЛЬШИХ обьёмов информации

Базы данных созданы для поиска и выборок.

А если там всего лишь надо по id выбрать одну-единственную запись, то файлы прекрасно подойдут.

 

[SiDChik]

дело в том, что нужно не только считать, но и обновить и создать.... мне файлы не нравяться только изза нагрузки на жёсткий диск.. Конечно БД тоже работает с жёстким... но перед записю она делает запись в память, а потом сразу пишет несколько записей в файл... Опять же для оптимизации.... Просто меня интересует как будет вести себя MySQL если в нём будет дофига записей....

 

[kruglov]

SiDChik
Ну, как бы даже виндоус умеет кэшировать работу с файлами... Нажмите Ctrl+Shift+Esc, там будет строчка "системный кэш". Угадайте, что это.

 

[avm]

вас кто-то ввел в заблуждение, что файловые операции не кешируются? кешируются и на уровне приложения, и на уровне ОС, и на аппаратном.

кроме того можно вообще организовать рамдиск мегов на 500 (для ваших целей хватит) и вообще все держать в ОЗУ изредка сливая по крону все на диск... хоть это и велосипед, но иногда некоторые вещи более технологично решать именно на "велосипедном" уровне.

я не за реализацию на файлах, просто говорить что "то-то лучше потому что я не знаю как по другому", это мягко говоря - плохо.

 

[AmdY]

kruglov
Ба́за да́нных (БД) — централизованное хранилище данных, обеспечивающее хранение, доступ, первичную обработку и поиск информации.
http://ru.wikipedia.org/wiki/%D0%91%D0%B0%D0%B7%D1%8B_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85

avm
рамдиск мегов на 500 -

я так понимаю проект будет размещаться не на локальной машине?

 

[kamatoz]

SELECT count(datetime) FROM pos;
+------------------+
| count(datetime) |
+------------------+
| 401896405 |
+------------------+
1 row in set (0.00 sec)

и у Вас на 200к записей что-то тормозит??

 

[kruglov]

AmdY
Сейфы как бы тоже предназначены для хранения ценных вещей, но ценные мешки картошки там хранить будет довольно глупо, вообще говоря.

 

[AmdY]

kruglov
а каждую картошину хранить в отдельном мешке ещё глупее и мороки больше.

 

[avm]

AmdY
скорее картошка разложена на плоском столе (может и многоярусном - по каталогам) и у нас в руках простое приспособление для того чтобы дотянутся до любой из них. и никаких мешков...

-~{}~ 26.01.07 13:37:

Автор оригинала: AmdY
рамдиск мегов на 500 -
я так понимаю проект будет размещаться не на локальной машине?

ну на шареде такой проект размещать глупо вообще...

 

[AmdY]

Если будет размещаться не на компе, на котором БД тормозила, а на такой - читай kamatoz. Зачем тогда изобретать пятиколёсный велосипед?

 

[avm]

Автор оригинала: AmdY
Зачем тогда изобретать пятиколёсный велосипед?

да я согласен, что изобретать ничего не нужно...

Но справедливости ради: если специфика не требует выборок и поиска, а прямой доступ по id (суть - имя файла) будет достаточным, то сами по себе соединения php-скриптов с сервером БД (если сервер на другой машине) уже являются лишней "прокладкой". А если при такой организации доступа к данным, SQL сервер держать на одном хосте с web-сервером, то тогда вообще непонятны преимущества (ну кроме возможности последующего их разнесения по разным хостам), зато явно заметны недостатки (сервер бд лишь отжирает озу под себя и свой кеш в котором он держит индексы) в виде постоянно дергаемого свопа, да и внутрисистемные сокетные соединения никто не отменял (которые хоть и работают быстро, но нах не нужны)

 

[Фанат]

и не надоело вам =)

 

[AmdY]

avm
если специфика не требует выборок и поиска, а прямой доступ по id (суть - имя файла) будет достаточным
--------------------------------------------------
с этой частью согласен.
ну а файловая система тоже быть разнесена. здесь много зависит от файловой системы и квот на ноды(они тоже могут быть).
Для меньшего количества можно использовать файлы (особенно xml), для большого количества только БД - это универсальнее, надёжнее, удобнее. А скорость это ещё нужно посмотреть