Форум MySQL

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

Вообщем такое дело, надо мне поставить сервак, накопитель, т.е. базу куда тупо будут вносить данные. Все это я умею, тока в качестве базы всегда юзал MYSQL

Дело в том, что данные в эту базу вносить будут интенсивно и в конце года наверное будет до 300-500тыс записей, и все это дело будет увеличиваться каждый год

Я неплохо освоил MYSQL и вроде научился раборать с ним, НО как я уже понял по отзывам в инете для больших объемов лучше использовать MSSQL с которым я еще не сталкивался.

Еще эту базу будут многократно отгружать и загружать на другие сервера, а как говорит моя практика MYSQL очень капризен к такому, не редко я отгружал базу, и не мог потом ее не куда загрузить в том числе на тот же сервак. Возможно руки кревые не спорю и все же...

что мне делать? Взяться за MSSQL или можно выпрямить руки и опробовать MYSQL снова?

Очень нужен хороший совет : ) заранее спасибо

Проблема у вас не в MySQL vs MSSQL vs Oracle. Проблема у вас в том, что один сервер не справляется с таким объемом, чтобы вы туда не поставили. Любая СУБД требует "прямых" рук, в противном случае у нас бы давно был "Photoshop"-СУБД :), одна супер-популярная база данных универсал. Их же десяток - все они требуют изрядного искусства.

MySQL отлично может справляться с гигантскими объемами - пример тому Wikipedia, в которой 300-500 тыс записей даже не в год, а в день, смотрят её чуть не миллиард человек, а дамп ежедневно забирают десятки тысячи пользователей по всему миру и успешно разворачивают у себя на локальных машинах.

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

Советы:

1. Возьмите MSSQL - новый опыт никому не повредил, только помните, что все, что умеет делать MSSQL может делать и MySQL, с не меньшей скоростью. MSSQL не будет за вас думать, может лишь саму малость...

2. Возьмите MySQL и сконфигурируйте базу данных под вашу систему, предварительно развернув в облаке схему и протестировав, на реальных данных.

За MSSQL не скажу, а по MySQL такие рекомендации. 300-500тыс - это ерунда для любой базы данных. Понятное дело, что если планируется интенсивная запись не стоит выбирать движок MyISAM, который блокирует всю таблицу при любой вставке, только InnoDB с построчной блокировкой. Понятно, что если выбрали InnoDB, её нужно настроить: если запись идет реже одного раза в секунду, сбрасываем данные на жесткий диск в конце транзации

innodb_flush_log_at_trx_commit = 2

Если чаще одного раза в секунду

innodb_flush_log_at_trx_commit = 0

Сбрасываем данные на диск - раз в секунду (предполагается, что вы можете потерять транзакции за одну секунду, если сервер аварийно завершит работу).
Если планируется интенсивное чтение из базы данных то innodb_buffer_pool_size - не оставляем 128Мб по умолчанию, выставляем столько, каков объем вашей базы данных (+ запас, 1-2-4-8-16Гб или сколько у вас на сервере - это вполне себе нормальные значения для этого параметра). Понятное дело, что снимать дамп с сервера, на которая идет интенсивная запись, да и просто идти к нему с SELECT-запросами - это дурацкая затея, лучше организовать репликацию и снимать дамп с соседнего сервера.

3. Крайне желательно больше одного сервера. Репликация обязательна (копия базы транслируется с мастер-сервера на один или более слейв-серверов), хоть в случае MySQL, хоть в случае MSSQL. Организация базы данных на нескольких серверах, кстати позволяет настроить сервера по-разному. Например, на сервере, где выполняются INSERT-запросы убираем все индексы (чтобы ускорить вставку), а на slave-реплике, где выполняются SELECT-запросы, индексы оставляем (чтобы ускорить выдачу).

4. Чтобы вы не выбрали, у желателен сервер с SSD-дисками, выделенный сервер тысяч за 200 000 рублей также очень приветствуется (понятное дело, если в бюджет влазите).

5. Чтобы вы не выбрали, у вас всегда есть запасной "ход конем" - заводите 100 таблиц и пишите в разные таблицы и записываем в них новые записи в случайном порядке. Последовательно обходим таблицы и агрегируем данные из них в общую таблицу-сток (этому приему 100 лет - именно так масштабируется запись). Все или часть из этих 100 таблиц могут располагаться на разных серверах. Как вариант - репликация по схеме кольцо (как раз для интенсивной записи, так как репликация по схеме звезда не масштабирует запись) или кластер. Но не советую, ни кольцо, ни кластер - намучаетесь.
Да, если собираетесь писать в разные таблицы, понятно, что табличное пространство нужно разбить, так, чтобы каждая таблица "жила" в отдельном файле

innodb_file_per_table=1

Резюме: без разницы какая у вас база данных, рано или поздно один сервер не справится с задачей, чтобы на него не было установлено. Если вы потратили месяцы и годы на разработку приложения, работающего с одним сервером - плохо дело. Лучше сразу масштабировать решение на несколько серверов. Все крупные базы данных это умеют. Выбирают обычно то, что лучше всех знают, потому что сложностей и так будет хватать (или дешевле в обслуживании - если вам потребуется писать на десяток Windows-серверов, лучше сразу прикиньте - потянете ли по бюджету).

Только одна поправка:

> все, что умеет делать MSSQL может делать и MySQL, с не меньшей скоростью.
Нет, нет и нет. Никак и никогда нет =)
Все зависит от сложности обработки данных.
Если из них нужно делать голые выборки, то да.
Если по ним нужно делать анализ, статистику и т.п., то попробуйте в MySQL реализовать PIVOT или оконные функции.
Это все возможно, но только на CASE'ах, лишних вложенных подзапросах и переменных, по которым применимо WHERE, только после того как они будут расчитаны для всей таблицы.... Что не положительно влияет на скорость.

P.S. Oracle это все, кстати, тоже умеет на сколько я знаю.

Согласен, у Oracle или MS SQL гораздо более развитый SQL, с этим не поспоришь и инструменты анализа более продвинутые...

я вам очень признателен и благодарен, почитав ваши советы я пришел к тому что сказал cheops:

...Выбирают обычно то, что лучше всех знают...

я знаю что рано или поздно приду к MSSQL но пока что в моих жилах течет MYSQL : )

и еще меня вот это очень насторожило:
Не факт, что MSSQL, которую вы не знаете, вам удастся настроить лучше. Не факт, что операции с ней вам будут удаваться проще, особенно, если организуете базу данных не удачно

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

дело в том что, интерфейс будет такой, заполняем 10 форм в каждой по 14 ячеек с данными (ФИО мест.жит и т.д.) а потом отправляем все на сервер, это каприз заказчика, в итоге 140 запросов только с одного рабочего места, а рабочих места в одном бюро до 10-15, а количество бюро 15.

Хотя я думал сделать каждую форму как одно предложение с уникальным разделителем между ячейками и того 10 длинных строк запросов а там на месте уже их разбить explod'м, ну это не разгружает MYSQL он по любому должен создать 10 строк и занести в каждую 14 ячеек данных. Другими словами в пик рабочего времени на сервак посыпяться запросы.

и при таком раскладе какое значение мне выставить в innodb_flush_log_at_trx_commit?
интенсивного чтение думаю не будет, хотя все может быть.

и еще я не до конца понял вот это:
Да, если собираетесь писать в разные таблицы, понятно, что табличное пространство нужно разбить, так, чтобы каждая таблица "жила" в отдельном файле

я думал о том чтоб каждому бюро сделать отдельную таблицу, если вы про это, но их потом надо будет отгружать загружать и т.д. и я подумал все же оставить все в одной таблице, с другой стороны она через годика 2-3 растолстеет и будет у меня на шее как якорь, помню 60мб база в 120тыс строк отгружалась минут 20-30 а если будет в 1млн или 2млн уже представляю свои мучения... готов выслушать все ваши недовольства по поводу моих неопытных решении : )

>я знаю что рано или поздно приду к MSSQL но пока что в моих жилах течет MYSQL : )
Отлично, чем больше баз данных знаете, тем лучше.

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

1. сложно простыми инструментами
2. легко, сложными инструментами

Сложность никуда не девается, она либо остается в ходе решения задач, либо в ходе изучения сложных инструментов.

>дело в том что, интерфейс будет такой, заполняем 10 форм в каждой по 14 ячеек с данными (ФИО мест.жит и т.д.) а потом
>отправляем все на сервер, это каприз заказчика, в итоге 140 запросов только с одного рабочего места, а рабочих места в одном
>бюро до 10-15, а количество бюро 15.
Если это вставка, то достаточно одного многострочного INSERT-запроса вместо 140.

>и при таком раскладе какое значение мне выставить в innodb_flush_log_at_trx_commit?
Раз в секунду

>я думал о том чтоб каждому бюро сделать отдельную таблицу, если вы про это, но их потом надо будет отгружать загружать и т.д.
>и я подумал все же оставить все в одной таблице, с другой стороны она через годика 2-3 растолстеет и будет у меня на шее как
>якорь, помню 60мб база в 120тыс строк отгружалась минут 20-30 а если будет в 1млн или 2млн уже представляю свои мучения...
>готов выслушать все ваши недовольства по поводу моих неопытных решении : )
Вам нужен выделенный сервер или виртуальный сервер в облаке и доступ к нему по SSH, дамп же создавать и разворачивать в командной строке - дамп 60Мб базы данных создается за секунду, сжимается еще одну секунду, получившийся сжатый файл перегоняется меньше минуты. По меркам баз данных - это очень небольшая база данных. 1Gb - это тоже очень небольшая база данных. 10Gb - средняя база данных. 500Gb - крупная база данных. Если на виртуальном хостинге помимо вас еще 200 проектов - все будет работать не очень быстро, особенно, если работаете через Web-интерфейс. Лучше освоить хотя бы базовые операции с командной строкой, особенно, если будете работать с MySQL.

Спасибо люди, тут мне как всегда хорошо и четко все объясняют, а cheops'у надеюсь когда-нить пожму руку, вы мне очень помогли за весь мой период веб деятельности