Помогите выбрать СУБД (большие объемы данных)

[Ashotovich]

Помогите выбрать СУБД (большие объемы данных)

Всем доброго времени суток.
Проблема в следующем: разработали ДБ на Oracle, но возникли проблемы с законностью использованию оного в коммерческих целях (лицензия стоит порядка 40000 долларов). Так что придется мигрировать на какую-нибудь бесплатную СУБД - MySQL, PostgreSQL или еще что.
Структура самой базы достаточно несложная, скрипты можно оптимизировать таким образом, что не потребуются триггеры, запрещающие удалять записи, имеющие дочерние записи и пр.
Но основная проблема вот в чем. За год в БД будет набираться порядка 1 500 000 записей в самой большой таблице. И есть опасения того, что, например, MySQL такие объемы не потянет. Посоветуйте, пожалуйста, СУБД из бесплатных, которая стабильно может работать с большими объемами данных.

Заранее спасибо.

С уважением, Ashotovich

 

[tony2001]

>За год в БД будет набираться порядка 1 500 000 записей в самой большой таблице.
1 500 000 - это не "большие".
это так, "есть немного".

любая БД "потянет" объемы на порядки большие (если говорить о хранении и работе с данными).
другое дело, что при определенной проблеме с руками можно сделать себе проблемы и на 1K записей.

 

[Ashotovich]

Thx за быстрый ответ.
Тогда вопрос вот в чем: где эти самые кривые руки могут проявиться? В чем можно накосячить при работе с MySQL?

 

[tony2001]

гм.
никакой специфики при работе с MySQL в этом смысле нет.
базу просто нужно проектировать грамотно и про индексы не забывать там, где они нужны.

 

[Ashotovich]

Ну базу-то спроектировать грамотно получится. А вот при индексы МуСКУЛьные слышал, да что это такое - не знаю. Опиши, плииз, в двух словах.

 

[Ashotovich]

На самом деле про индексы я зря спросил. Яндекс мне поможет.

Вопрос последний (или не очень ): какая конфигурация сервра подойдет для работы с базой, в которой остальные таблицы - на пару порядков меньше, количество одноременных пользователей - от 0 до 50, каждый пользователь обращается к базе, допустим, десять раз в минуту?

Заранее спасибо.

 

[phpdemon]

Лучше наверное все же не MySQL, а PostgreSQL
Мы у себя в конторе используем, нарекиний на постгрес нет.
Опять же и тригеры, и хранимые процедуры, все в постгресе нормально работает.

 

[tony2001]

phpdemon:
>Мы у себя в конторе используем, нарекиний на постгрес нет.
ну и отлично. используйте.
вопрос был конкретный, как и ответ.
а что именно использовать - решит сам Ашотович.

 

[ratman]

есть такая буква

Рекомендую посмотреть на interbase/firebird

http://www.ibase.ru/

IMHO для больших баз и сложных структур более привлекателен

 

[Ashotovich]

Спасибо за советы. Пока что мигрируем на MySQL 3.x. Проблему Foreign Keys решили через "одно место" - пользователям запрещены реальные операции по удалению записей из базы, записи просто делаются "неактивными". К счастью, операции по удалению не являются основными при работе с базой, так что жить можно. Когда БД разрастется до сотен тысяч строк - отрапортую.

 

[Апельсин]

> Пока что мигрируем на MySQL 3.x.

а почему тогда не на 4.0.х, раз уж выбрали MySQL?

 

[Ashotovich]

Потому как с 4.0.* еще разбираться надо. Хотя, на самом деле, сечас хостинг меняю, там как раз она стоит. Надеюсь на 100% совместимость...

 

[si]

Кстати не следует забывать что база в 10G под MySQL в том же PG будет имень больший размер, на сколько сказать не могу, но думаю значительно

 

[Ashotovich]

Конечно, больший. А на Оракле - еще больший. Там же всяких служебных данных хранится вагон и маленькая тележка. А MySQL - СУТ, Система Управления Таблицами - ничего лишнего (горько усмехаюсь)... Зато шустро работает.

 

[Sad Spirit]

Автор оригинала: si
Кстати не следует забывать что база в 10G под MySQL в том же PG будет имень больший размер, на сколько сказать не могу, но думаю значительно

Кстати не следует забывать, что в текстовых файлах база в 10G под MySQL будет иметь меньший размер. Насколько --- сказать не могу, но думаю --- значительно.

 

[fixxxer]

А если текстовые файлы еще gzip-ом сжать и динамически распаковывать при поиске - так вообще на дискетку всё можно уместить!

 

[si]

Кстати не следует забывать, что в текстовых файлах база в 10G под MySQL будет иметь меньший размер. Насколько --- сказать не могу, но думаю --- значительно.

есть нормальный скрипт для конвертации дампа mysql в pg ?

 

[SashOk]

Проблему Foreign Keys решили через "одно место"

Можно использовать InnoDB вместо MyISAM -- там внешние ключи поддерживаются

 

[cryo]

Все равно лучше Firebird/Interbase. Все что нужно есть, бесплатная, компактная по размеру (есть вообще вариант всей СУБД в виде одной dllки). Кроссплатформенная (Win, Linux, FreeBSD точно плюс еще много себе). Внешние ключи, вложенный запросы, триггеры, процедуры, генераторы, нормальная поддержка транзакций с разными уровнями изоляции. На выбор SuperServer/ClassicServer (модель распределения обработки запросов по потокам/процессам). Много информации и документации в том числе на русском языке. И php подключается легко и непринужденно Кароче говоря http://www.firebirdsql.com, http://www.ibase.ru

 

[Ashotovich]

Автор оригинала: si
есть нормальный скрипт для конвертации дампа mysql в pg ?

Есть недурственная программка: MySQLFront (www.mysqlfront.de, лучше пользоваться версией 2.5 т.к. 3.0 еще глючит жестоко, хотя и поддержитвает работу с форматом InnoDB). Она экспортирует дамп MySQL в виде sql-файла, который содержит совокупность SQL-команд создания БД в простом текстовом формате. Этой файл, насколько я понимаю, безболезненно импортируется в PostgreSQL - можно даже PHP-шным скриптом.