да, SE1, при шардинге ничего кроме SE1 и не нужно.
в 2016, когда они запускали постгрес, можно было уже по 40+ ядер на 2 сокета SE1 ставить. куда больше то?
а зачем с такой архитектурой понадобился enterprise edition? все что нужно, начиная с standby (тот который SE standby на скриптах), заканчивая partitioned view с его partition elimination есть в SE edition, которое стоило уже в те времена лишь $6k на сокет?
partitioned view + partition elimination замечательно бы развели бы старые майлы на HDD, свежие на SSD. выглят что в яндексе просто не было хардкорного ораклойда.
звучит бредово.
если речь о EE редакции то там ценник $25 000 за ядро ($50 000 за «ядро» * 0.5 коефициент x86) + каждая опция отдельно. типа партишенинг + $25к*0.5 + дата гвард +…
если речь о SE то там $6k на сокет. не ядро, сокет.
т.е. о чем бы речь не шла, все мимо.
откуда на 20 процев пол ляма? SE стоит $6к на проц (именно проц, не ядра), 20 штук с супортом $141k, со стандартными скидками и SE стебаями вышло бы отсилы $200к
по партишанам во первых у них партиций и так нет, во вторых в SE есть partition view (PARTITION_VIEW_ENABLED)
http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=801747&msg=9747235
т.е. эти лапти могли бы на SE архивированные года уносить на HDD свежие года на SSD, объединять вьюшкой и оптимизатор оракла сам бы догадывался (partition elimination) не трогать таблицы 2010 года, если обращение идет к 2017 году.
вобщем вопрос так и повис в воздухе, чего SE редакцию не поставили?
явно было бы на порядок дешевле переезда на постгрес
а менять одну рсубд на другую путь в никуда, яндексу явно надо было куда-то в сторону бигдата смотреть, hadoop/spark скорее всего
ну в статье говориться что стендбай для красоты стоял: Мы стали делать базы поменьше и по две реплики в каждом шарде. Это позволило нам заворачивать читающие нагрузки на реплики. То есть в Oracle всё обслуживалось с мастера
в 2016, когда они запускали постгрес, можно было уже по 40+ ядер на 2 сокета SE1 ставить. куда больше то?
partitioned view + partition elimination замечательно бы развели бы старые майлы на HDD, свежие на SSD. выглят что в яндексе просто не было хардкорного ораклойда.
если речь о EE редакции то там ценник $25 000 за ядро ($50 000 за «ядро» * 0.5 коефициент x86) + каждая опция отдельно. типа партишенинг + $25к*0.5 + дата гвард +…
если речь о SE то там $6k на сокет. не ядро, сокет.
т.е. о чем бы речь не шла, все мимо.
по партишанам во первых у них партиций и так нет, во вторых в SE есть partition view (PARTITION_VIEW_ENABLED)
http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=801747&msg=9747235
т.е. эти лапти могли бы на SE архивированные года уносить на HDD свежие года на SSD, объединять вьюшкой и оптимизатор оракла сам бы догадывался (partition elimination) не трогать таблицы 2010 года, если обращение идет к 2017 году.
явно было бы на порядок дешевле переезда на постгрес
а менять одну рсубд на другую путь в никуда, яндексу явно надо было куда-то в сторону бигдата смотреть, hadoop/spark скорее всего