Oracle 12.2 out of the box sharding?

Навеяно сессиями на OOW2015.
Идеи к чему они это прикрутят? Интегрированный в БД голденгейт? Что-то новое и доселе невиданное?

ИМХО если это сделают без кучи ограничений, то это очень полезная feature.

автор

Linear Scalability and Fault Isolation with the Next Release of Oracle Database 12c [CON8829] Srinagesh Battula, Senior Principal Product Manager, Oracle Mark Dilman, Director, Software Development, Oracle Database sharding is an architectural pattern where data is horizontally partitioned across multiple discrete databases that share no hardware or software. It provides linear scalability and complete fault isolation for transaction processing applications designed for a sharded architecture—attributes that are not possible by scaling-out or scaling-up a single database. Join this session to hear Oracle Development present how the next release of Oracle Database 12c automates the deployment of a sharded architecture, and enables elastic scaling, rebalancing, data-dependent routing, and cross-shard queries. And it does all this while rendering strict consistency, the full power of SQL, developer agility with JSON, and the proven enterprise qualities of Oracle Database.

автор

Deep-Dive into High Availability with the Next Release of Oracle Database 12c [CON8827] Wei Hu, Vice President - High Availability Technologies, Oracle Have you ever wished you had the army of PhDs needed to achieve the level of high availability (HA) and scalability of Google or Facebook? Ever wondered if you could utilize similar techniques on commodity platforms without sacrificing the enterprise qualities of Oracle Database? Both are possible using a new HA architecture included with the next release of Oracle Database 12c. Join this session to learn about designing transaction processing systems for linear scalability with complete fault isolation—on commodity hardware without shared storage. Learn about the new enhancements to existing HA capabilities for planned maintenance, HA, disaster recovery, and self-repair that enable best-in-class availability for databases of any size, on any platform.

информация с семинара oracle от 30/11/2016 про новые возможности 12.2:
Oracle в новой версии 12.2 получает функционал Sharding (нарезку монолитной базы на отдельные ноды) - shared nothing (подобно Терадате), когда части одной таблицы размазаны по всем нодам и одна строка существует только на одной из них. Его решили включить в СУБД, т.к. многие крупные заказчики (в т.ч. LinkedIn) уже сделали на Oracle самописные подобные решения, а желающих этот функционал из коробки еще больше.

обзор с картинками здесь: http://docs.oracle.com/database/122/ADMIN/sharding-overview.htm#ADMIN-GUID-0D1CBC48-93D0-41A9-9786-4285FE060C97

Сейчас Sharding позиционируется как решение проблемы линейной масштабируемости для OLTP, т.к. существуют ограничения на работу с такой базой в режиме
DWH. Консультант выдал основное: центральная нода-координатор,
которая выполняет работу по сведению подитогов из подчиненных нод (select count(*) from {node1 .. nodeX}) в единый итог,
пока не может автоматически записать результат этого сводного запроса обратно - в таблицу, размазанную на разные ноды.
Но может работать с нодами на запись "по одной" в единой транзакции, подробнее про ограничения на SELECT и DML здесь:

http://docs.oracle.com/database/122/ADMIN/sharding-data-routing.htm#ADMIN-GUID-E58EA3C1-8EB6-4F51-88BD-FC887035A624
раздел 54.2.3 Querying and DMLs Using Proxy Routing

При этом нода-координатор может быть мощным RACом для повышения своей пропускной способности, а ноды-подчиненные - дешевыми серверами.

Технология готова к облачным и гибридным подходам (часть или все ноды могут быть в облаке).

Alexus12

информация с семинара oracle от 30/11/2016 про новые возможности 12.2: Oracle в новой версии 12.2 получает функционал Sharding (нарезку монолитной базы на отдельные ноды) - shared nothing (подобно Терадате), когда части одной таблицы размазаны по всем нодам и одна строка существует только на одной из них. Его решили включить в СУБД, т.к. многие крупные заказчики (в т.ч. LinkedIn) уже сделали на Oracle самописные подобные решения, а желающих этот функционал из коробки еще больше.

Спасибо.

Документацию уже почитал. Как всегда у оракла, еще надо версии 2-3 чтобы допилить до используемого состояния.
Имеющееся самописное решение сильно гибче того, что пока показал оракл.

интересно что тут с лицензированием
сама фича будет платной или достаточно будет залицензировать бд на серверах ?

kinky cat
интересно что тут с лицензированием сама фича будет платной или достаточно будет залицензировать бд на серверах ?

Пока изменений в прайслисте нет. Но тем кому оно действительно надо, итак сидят на Unlimited License Agreement.
В том виде как оно сделано сейчас работать будет тяжело. Основные проблемы:
- MV для таблиц которые должны полностью копироваться, почему не streams\GG для почти реалтайм?
- нет мультимастер репликации

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

Решение очень нишевое, видимо кто-то в таком виде заказал или пробный шар, как отреагирует рынок :) Надо ждать нормального релиза и пробовать.

о1222

kinky cat интересно что тут с лицензированием сама фича будет платной или достаточно будет залицензировать бд на серверах ? Пока изменений в прайслисте нет. Но тем кому оно действительно надо, итак сидят на Unlimited License Agreement. В том виде как оно сделано сейчас работать будет тяжело. Основные проблемы: - MV для таблиц которые должны полностью копироваться, почему не streams\GG для почти реалтайм? - нет мультимастер репликации Нода координатор сама собирающая результаты с разных шард это здорово, но не понятно как будет себя вести оптимизатор вообще и в ситауциях когда канал связи с разными шардами неоднородный в частности. Когда "допилят" текущие ограничения на запросы к шардам? Решение очень нишевое, видимо кто-то в таком виде заказал или пробный шар, как отреагирует рынок :) Надо ждать нормального релиза и пробовать.

1) По первому вопосу: streams officially deprecated, GG будет требовать лицензию. В результате сделали кое-что другое, скоро будет.
2) "нету мультимастер репликации". Как нету? GG (с auto-CDR и без) поддерживается. Чего пока нету-это комбинации GG c DG для мультимастра+max protection в одном флаконе. Можно сделать руками впрочем: GG-based sharding+max.protection DG for each shard.
3) "непонятно как будет вести себя оптимизатор", "когда канал свзяи неоднородный". Тут долгий разговор, но вкратце: что в данный момент учитывается, так это предпочтение реплик из близлежащего к координатору региона.

NoPain
1) По первому вопосу: streams officially deprecated, GG будет требовать лицензию. В результате сделали кое-что другое, скоро будет.

То что недоделали это понятно, надо было что-то выкатить, это логично, понятно и традиционно для Оракла.

NoPain
2) "нету мультимастер репликации". Как нету? GG (с auto-CDR и без) поддерживается. Чего пока нету-это комбинации GG c DG для мультимастра+max protection в одном флаконе. Можно сделать руками впрочем: GG-based sharding+max.protection DG for each shard.

Координатор-нода будет знать об этом?
Так руками и сейчас делаем, вопрос в "из коробки".

Спасибо за ответ! Возможности попробовать по очевидным причинам пока нет, так что даже то что есть сейчас в голове может лежать не правильно, т.к. рассматривается через призму текущего use case и реализации.

То что недоделали это понятно, надо было что-то выкатить, это логично, понятно и традиционно для Оракла.

(говорю не от лица компании, если что)
Ну: идеологически выверенным решением было сфокусироваться на OLTP performance, direct shard access, и покрытии фич NoSQL конкурентов. Поэтому концепция duplicated tables была не приоритетной.

После появления соответсвующего требования от критической массы заказчиков смогли убедить начальство, что обновление словарей (duplicated tables) в рамках транзакции которая меняет шард-данные -вещь важная.

2) "нету мультимастер репликации". Как нету? GG (с auto-CDR и без) поддерживается. Чего пока нету-это комбинации GG c DG для мультимастра+max protection в одном флаконе. Можно сделать руками впрочем: GG-based sharding+max.protection DG for each shard. Координатор-нода будет знать об этом?

Нет координатор будет знать только о GG.
Вы создаете GG-based шард конфигурацию.Все хорошо, координатор знает о всех узлах и менеджит их, но к сожалению GG не оебспечивает zero data loss.
Поэтому, чтобы его добиться, для каждого шарда, создается DG со своими стендбайми (non-active) в режиме max protection. Координатору о них знать не надо, потому что failover/switchover не нужен (если узел падает, для DML будут использовать реплики на других шардах, а соответствующий стендбай нужен только для восстановления).

При этом мы понимаем, что это
a) костыль (стэндбай который не используется для failover) и
б) адская нагрузка на DBA и рассмотриваем вышеописанное решение как временное (одна компания очень настойчиво требует автоматизации решения, подобного вышеописанному).

Спасибо за ответ! Возможности попробовать по очевидным причинам пока нет, так что даже то что есть сейчас в голове может лежать не правильно, т.к. рассматривается через призму текущего use case и реализации.

Не за что. Если вы в общих чертах опишете свой use-case, буду очень благодарен.

NoPain
Не за что. Если вы в общих чертах опишете свой use-case, буду очень благодарен.

Он не один в самом деле :) Приложения которые исторически были монолитными надо шардить, в одном месте уже сделали, управлять этим хозяйством адский ад, принимая во внимание очень активную разработку самого приложения.

Другое приложение надо делать, но в бюджет такой объем работ не лезет, потому и хочется "из коробки". Хочется понять куда эта фича направляется и можно ли её будет продать клиенту на Оракле или смотреть на его давнишнюю мечту переделать на mysql. C mysql надо будет раз в 10-20 больше шард, это будет вообще адскский ад^2

Можно в почте? natafeon@gmail.com

о1222
NoPain Не за что. Если вы в общих чертах опишете свой use-case, буду очень благодарен. Он не один в самом деле :) Приложения которые исторически были монолитными надо шардить, в одном месте уже сделали, управлять этим хозяйством адский ад, принимая во внимание очень активную разработку самого приложения.

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

о1222
или смотреть на его давнишнюю мечту переделать на mysql.

mysql уже научился делать ALTER TABLE ADD COLUMN без необходимости перепахивания ВСЕЙ таблицы?

о1222
C mysql надо будет раз в 10-20 больше шард, это будет вообще адскский ад^2

вы просто не умеете его использовать. его применение - это key-value сторидж, где key это varchar(255), а value - это денормализованный блоб (чаще всего json).

подробности тут: (3:28)