LINUX.ORG.RU

выбор базы данных


0

0

есть задач: 1.5G информации в месяц необходимо поместить в БД использование только как хранилище данных, только Select

есть вопрос: MySQL? Postgres? Oracle(очень бы не хотелось, ограничены ресурсы)?

к людям имеющим опыт: что выбрать?


А вообще вам SQL нужен? Может лучше key-value базу типа bdb или qdbm? Есть так же интересная штука под названием fastdb. Если именно нужен SQL, то посмотрите в сторону SQLite.

krum
()

Не совсем понятно насчет "только select" - загрузка происходит пакетно раз в месяц, с остановкой читателей? Или льется постоянно?

А старые данные - заменяются, или оно будет 20 гигов через год?

Какая структурная сложность - просто одна большая-большая таблица, или что-то развесистое?

Сколько читателей будет одновременно? Какой примерный объем выборки? Будет ли делаться аггрегация средствами БД, или просто высасываться, и обрабатываться приложением?

Вообще - на первый взгляд, скорее мускуль. Но если база сложная, будет много join-ов - то, возможно, Postgres будет быстрее.

anonymous
()
Ответ на: комментарий от krum

krum (*) (16.02.2007 21:15:57):

> А вообще вам SQL нужен? Может лучше key-value базу типа bdb или qdbm? Есть так же интересная штука под названием fastdb. Если именно нужен SQL, то посмотрите в сторону SQLite.

Почти "+1". Только qdbm и Ко. имеют проблемы с 2 ГиГ. Как и "голый" SQLite на 32 bit.

Я бы (если не нужен SQL) обошелся просто самодельно индексированными файлами, а если все же нужен select, то наваял бы что-нибудь самодельное с использованием SQLite - например, по мере заполнения базы данные сбрасываются в константный хэш типа http://www.corpit.ru/mjt/tinycdb.html который при необходимости легко поднять в реляционный вид.

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

Ксати? такой ещё вопрос: есть ли субд, которые позволяют как быстрый доступ через key-value, так и через более медленный sql?

krum
()
Ответ на: комментарий от krum

Бывают SQL-ные надстройки над BerkeleyDB. Например, на DBD::AnyData совершенно несложно такое сделать.

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

anonymous
()
Ответ на: комментарий от krum

> ...как быстрый доступ через key-value, так и через более медленный sql?

На уровне "готового" API -- не знаю. Но, AFAIK, Мускуль внутри БерклиДБ использует?

Вообще, надо отдавать себе отчет в том, что хэши и реляционные структуры -- разного уровня абстракции. Примерно как кластеры на диске и файловая система...

Всегда ли есть возможность напрямую прочитать сектор с диска, минуя файловую систему? -- Почти всегда. -- А кластер?...

Die-Hard ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.