|
|
|
Возможности MySQL
|
|||
|---|---|---|---|
|
#18+
Рассматриваю не применить ли MySQL в одном из проектов. Предположим, поставлю MySQL на сервер с 512 ГБ ОЗУ, 50+ ядер процессора, дисковая система - SAN с SSD. Ожидаемый размер БД - 300-400 Гб. Нагрузка - 200-300 довольно сложных запросов на чтение в секунду, под каждый из них пусть будут подходящие индексы. И 300-500 вставок и модификаций данных в секунду. Требования по доступности 24/6. 24 нужны честные, т.е. время когда можно что-то сделать без влияния на пользователей нет от слова совсем, сотни пользователей вовсю что-то делают даже глубокой ночью. Соответственно вопрос - потянет ли такое MySQL? Насколько это рискованно? Есть ли примеры? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2016, 15:36 |
|
||
|
Возможности MySQL
|
|||
|---|---|---|---|
|
#18+
andsmТребования по доступности 24/6. 24 нужны честные То есть уже отказоустойчивый кластер... andsmпотянет ли такое MySQL? Ну... потянуть-то потянет, вот только явно не в Community-варианте. А раз всё одно не забесплатно, то лучше всё-таки подумать о несколько более промышленном сервере БД. ИМХО. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2016, 15:52 |
|
||
|
Возможности MySQL
|
|||
|---|---|---|---|
|
#18+
Хороший вопрос, вкусный, примерно как на радио спросили, что лучше, мерс 300-й или Камаро. В смысле, правильное ли это архитектурное решение, все вот это на один инстанс СУБД поселить. Абсолютно не могу сказать, где здесь узкое место, на тему аж подписался. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2016, 15:59 |
|
||
|
Возможности MySQL
|
|||
|---|---|---|---|
|
#18+
andsm50+ ядер процессораВот тут уже берут сомнения. У MySQL есть проблемы с распределением нагрузки на много ядер. И настолько большое число ядер, насколько я понимаю, может утилизировать только версия 5.7, которая из состояния беты вышла совсем недавно. См. http://dimitrik.free.fr/blog/archives/2015/10/mysql-performance-yes-we-can-do-more-than-16m-qps-sql-on-mysql-57-ga.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2016, 16:11 |
|
||
|
Возможности MySQL
|
|||
|---|---|---|---|
|
#18+
andsm, 50 ядер - это что-то из разряда фантастики, не то чтобы не может быть, а просто смысла нет, вся их производительность уйдет на состязания за доступ к памяти. на скоко я знаю такие большие компьютеры даже не делают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2016, 01:26 |
|
||
|
Возможности MySQL
|
|||
|---|---|---|---|
|
#18+
MasterZivandsm, 50 ядер - это что-то из разряда фантастики, не то чтобы не может быть, а просто смысла нет, вся их производительность уйдет на состязания за доступ к памяти. на скоко я знаю такие большие компьютеры даже не делают.Если толково все сделано, как в Солярисе например, там каждый процессор имеет доступ к своему участку пямяти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2016, 02:00 |
|
||
|
Возможности MySQL
|
|||
|---|---|---|---|
|
#18+
интересный воплосик... ) теоретически ваши ожидаемые 300-400 Гб влезут в память 512Г + останется место под времянку-кэш для "сложных запросов" все будет зависеть от качества памяти ... ядер (и кулеров :-) ) Теория, думаю не поможет, здесь нужен "Эмпирический подход" Несложно (в смысле доступно) такие объемы протестировать, уменьшите все ровно в 50 раз: 10Гб ОЗУ, 1 ядро, ожидаемый размер 8Г, вполне живой экземпляр (или нет.....???......) обкатайте такой вариант и все будет видно. В дальнейшем все будет зависеть от характера БД (чего там больше, чтения или записи...) может лучше будет кластер или что то еще. И Оракл тоже можно загнать в глобальный тупик, такой, что он шевелиться перестанет... кстати, можно аккуратненько озадачить их умы в техподдержке, как лучше Андербрейк+Оракле использовать с такими объемами.... Может какие выкладки предварительные дадут.... с последующей поддержкой :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2016, 09:53 |
|
||
|
Возможности MySQL
|
|||
|---|---|---|---|
|
#18+
Alex_Ustinovкстати, можно аккуратненько озадачить их умы в техподдержке, как лучше Андербрейк+Оракле использовать с такими объемами.... Может какие выкладки предварительные дадут.... с последующей поддержкой :-)И с 7-значным ценником :) Идею итеративного тестового подхода поддерживаю. Сначала на стенде покатать 1/50 нагрузки, затем 1/5, а затем уж думать, годится ли тут MySQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2016, 10:01 |
|
||
|
Возможности MySQL
|
|||
|---|---|---|---|
|
#18+
miksoft, да не, ценник это понятно... идея в "выуживании информации", должны же они на рекламу "бренда" обращать внимание... хотя практика показывает что будет элементарный "зацеп" клиента ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2016, 10:12 |
|
||
|
Возможности MySQL
|
|||
|---|---|---|---|
|
#18+
Я лично не верю в приворот по фотографии консультации по умозрительным исходным данным (за исключением мелких примитивных случаев). И, уж тем более, по данным на форуме. У нас был опыт запросов конфигураций серверов под нагрузку у крупных поставщиков. И каждый раз мы получали в разы более мощную конфигурацию, чем реально надо было. Оно и понятно, им и продать побольше хочется, и не опростоволоситься с прогнозом. Спасало только то, что у нас уже был опыт эксплуатации базы на самосборном железе и не слишком быстрый рост числа пользователей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2016, 10:21 |
|
||
|
Возможности MySQL
|
|||
|---|---|---|---|
|
#18+
miksoft, беда такая же... сервера по 5-10 тдолл стоЯт практически как файл серверы, закупались невеждами без анализа, то что с умом руками собрано в 10 раз дешевле пашет с радостью достойного сервера ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2016, 10:34 |
|
||
|
Возможности MySQL
|
|||
|---|---|---|---|
|
#18+
Alex_Ustinovсервера по 5-10 тдолл стоЯт практически как файл серверы, закупались невеждами без анализа Наличие свободных мощностей ещё никому не вредило... к тому же всегда есть возможность за счёт их наличия "уплотниться" (с учётом прогнозируемого масштабирования, понятно), и под новую задачу не закупать новое оборудование, а освободить ресурсы существующего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2016, 10:41 |
|
||
|
Возможности MySQL
|
|||
|---|---|---|---|
|
#18+
Relic HunterMasterZivandsm, 50 ядер - это что-то из разряда фантастики, не то чтобы не может быть, а просто смысла нет, вся их производительность уйдет на состязания за доступ к памяти. на скоко я знаю такие большие компьютеры даже не делают.Если толково все сделано, как в Солярисе например, там каждый процессор имеет доступ к своему участку пямяти. это все делают, только проблема в том, что иногда задачка нужны общие данные... в общем 16-32 процессора это примерно та граница, выше которой идти не стоит. Дальше нужны распределенные вычисления. Конечно же, все зависит от задач, но это вот мой опыт (и не только мой) работы с большими данными на базах данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2016, 10:46 |
|
||
|
Возможности MySQL
|
|||
|---|---|---|---|
|
#18+
ну и по поводу mySQL, хотел написать, но не было времени. В общем, все что угодно, но не MySQL. почему - у него очень плохая архитектура. нет использования кэша для myISAM. нет своей многозадачности, все на потоках операционки. нет параллельного исполнения запросов. да и вообще, говно СУБД, хватает только в вебе никому ненужные данные держать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2016, 10:53 |
|
||
|
Возможности MySQL
|
|||
|---|---|---|---|
|
#18+
Akina, ) высвобождение и перепрофилирование гараздно накладнее... бумажки, отделы ПЭО ОБУ кАпание на мозги, перенос информации... бред на уровне "человечины"... да и если бы платили соответственно за умные решения ... офффтоп... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2016, 10:55 |
|
||
|
|
start [/forum/topic.php?fid=47&msg=39169312&tid=1832162]: |
0ms |
get settings: |
8ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
180ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
68ms |
get tp. blocked users: |
2ms |
| others: | 209ms |
| total: | 504ms |
| 0 / 0 |
