MySQL vs PostgreSQL
- Автор темы WebByte
- Дата начала
WebByte
Проходящий мимо
Фанат,
ты, конечно, в чем-то прав, но абсолютно не умеешь (или не хочешь) доносить нормально то, что хочешь сказать. Меня абсолютно не интересует твое мнение, как мне разрабатывать и как не разрабатывать систему. Я задал конкретный вопрос — что лучше использовать для системы с большими нагрузками и объемами данных. Сейчас Мускул у меня работает на относительно малых объемах — 2-3 миллиона строк, поэтому я не могу определить, как он себя будет вести на 200-300 миллионах. Поэтому и спросил коллективный разум.
За подсказку, что есть поиск, спасибо, не знал
~~ upd 11:03 ~~
Кстати, кое-что в поиске-то нашел. В деталях и факе — нет.
Если интересуют более точные данные о возможных объемах, то примерно так:
Имеется примерно 1-2 миллиона документов на удаленных серверах, которые минимум раз в день надо забирать, обрабатывать и строить индекс. Что-то вроде миниатюрной поисковой системы. Структурирование документов даст еще примерно 13-17 записей по разным таблицам на каждый из документов. Работа системы планируется на достаточно долгий промежуток времени, поэтому уже в ближайшее время разговор пойдет о нескольких сотнях миллионов записей.
ты, конечно, в чем-то прав, но абсолютно не умеешь (или не хочешь) доносить нормально то, что хочешь сказать. Меня абсолютно не интересует твое мнение, как мне разрабатывать и как не разрабатывать систему. Я задал конкретный вопрос — что лучше использовать для системы с большими нагрузками и объемами данных. Сейчас Мускул у меня работает на относительно малых объемах — 2-3 миллиона строк, поэтому я не могу определить, как он себя будет вести на 200-300 миллионах. Поэтому и спросил коллективный разум.
За подсказку, что есть поиск, спасибо, не знал
~~ upd 11:03 ~~
Кстати, кое-что в поиске-то нашел. В деталях и факе — нет.
Если интересуют более точные данные о возможных объемах, то примерно так:
Имеется примерно 1-2 миллиона документов на удаленных серверах, которые минимум раз в день надо забирать, обрабатывать и строить индекс. Что-то вроде миниатюрной поисковой системы. Структурирование документов даст еще примерно 13-17 записей по разным таблицам на каждый из документов. Работа системы планируется на достаточно долгий промежуток времени, поэтому уже в ближайшее время разговор пойдет о нескольких сотнях миллионов записей.
WebByte
Проходящий мимо
Под разработкой в данном контексте я имел ввиду проектирование структуры баз данных, структуру и код программной части итп. Об этом я спрашивать и правда не собираюсь.
Вопрос же в нагрузках на разные СУБД при больших объемах данных до этого передо мной не стоял, поэтому и спросил.
Боюсь, что нет. Даже в том прототипе, что сейчас работает (специально залез проверил), 3.5 миллиона записей, при том, что это лишь треть системы и не самая основная часть... Поэтому объем и правда будет большой...
А там и так не одна таблица
Сейчас 7 баз данных с разной структурой. Тут как раз понятно, что очень желательно прикидывать как часто будут нужны все записи и разносить по таблицам на каждый из периодов.
svetasmirnova
маленький монстрик
SID
Умное замечание. Особенно применительно к порядку записей thread starter-а.
Умное замечание. Особенно применительно к порядку записей thread starter-а.
Mescalito
Новичок
WebByte
раньше можно было бы однозначно сказать, что для таких объемов Postgres лучше, сейчас уже хз...
у меня на postgres'e на старом 7.3, база в день увеличивается на 2 - 2,5 млн. записей - работает вполне сносно и стабильно.
думаю на 8-ом будет еще лучше.
а почему mysql и postgres, почему не oracle например ?
кстати, а какие конкретно задачи, что храница будет ? есле не секрет , конечно.
раньше можно было бы однозначно сказать, что для таких объемов Postgres лучше, сейчас уже хз...
у меня на postgres'e на старом 7.3, база в день увеличивается на 2 - 2,5 млн. записей - работает вполне сносно и стабильно.
думаю на 8-ом будет еще лучше.
а почему mysql и postgres, почему не oracle например ?
кстати, а какие конкретно задачи, что храница будет ? есле не секрет , конечно.