Oracle выпустила СУБД NoSQL Database 2.0
1
Иллюстрация с сайта YouTube
Корпорация Oracle анонсировала второй крупный релиз своей NoSQL-СУБД, впервые представленной около года назад, — NoSQL Database 2.0.
NoSQL Database от Oracle — это база данных, хранящая пары ключей-значений и распространяющаяся в двух редакциях: бесплатной под свободной лицензией AGPL (Community Edition) и коммерческой (Enterprise Edition). В релиз NoSQL Database 2.0 были добавлены динамическое управление ресурсами (как вычислительными, так и хранимыми данными), поддержка хранения и получения больших объектов данных, таких как документы и изображения (Large Object API), улучшенная интеграция с СУБД Oracle и платформой Hadoop.
Кроме того, сообщается о новых успехах в производительности при использовании NoSQL Database в крупных кластерных инсталляциях.
Постоянная ссылка к новости: http://www.nixp.ru/news/12036.html. Дмитрий Шурупов по материалам oracle.com, h-online.com.
- Oracle Big Data Appliance — NoSQL-хранилище с Apache Hadoop от Oracle 6 октября 2011 г.
Apache CouchDB v2.0 — свободная NoSQL-СУБД стала кластерной
HBase 1.0 — крупный релиз распределенной нереляционной базы данных для Hadoop
ASF перевела свободный движок для SQL-запросов Drill в ведущие проекты
3 6
Apache Cassandra 2.0: легковесные транзакции, триггеры, улучшения в CQL 1
У NoSQL-БД MongoDB появился Hadoop Connector 1
Oracle Big Data Appliance — NoSQL-хранилище с Apache Hadoop от Oracle
Последние комментарии
-
OlegL, 17 декабря в 15:00 →
Перекличка
21
-
REDkiy, 8 июня 2023 года в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
кто-нть знает — зачем они такую штуку придумали? (просто интересно)
Что она должна заменить — вин-реестр, или лдап, или ещё зачем-то?
Не, это совсем не LDAP и не реестр, а для Big Data — см. «Oracle NoSQL Database Introduction Video»: www.youtube.com/watch?v=TfuhuA_uaho
У оракл под BigData есть специальный эплайнс Exadata. Который не включает ту самую NOSQL.
Не то, чтобы я был особо компетентен в продукции Oracle, но у неё же ведь есть и Big Data Appliance (на базе этой NoSQL)?
Есть, все верно. Я лишь хотел сказать, что BigData != NoSQL и традиционные RDBMS в BigData тоже успешно применяются.
А по поводу ссылки: имея софт, почему бы не продать еще и свое железо, если покупатель не против? :)
Просто есть целый круг задач, для которых классические реляционные СУБД не очень хорошо подходят и накладывают ряд ограничений, сильно усложняющих жизнь.
Для таких случаев сейчас часто используют одну из разновидностей NoSQL СУБД… в данном случае типа ключ-значение (примеры: memcached, redis etc …). Есть конечно же у другие, более сложные варианты ….
Факт, что этот рынок очень быстро растёт в последние пару лет и Oracle, очевидно, тоже хочет здесь свою долю + удовлетворить определенный спрос существующих клиентов (чтоб не мигрировали ненароком ;) ).
Да просто модно. В Энтерпрайзе это немаловажный фактор. ИТ-отделы должны тратить бюджеты, ИТ-компании их зарабатывать. На весенней конеференции SAP своей HANA хвастался и каждый второй bI-игрок представил свои решения для отчетности на iOS/Android. MS тоже со своими in-memory решениями покрасовалась.
Мода. Применимость, особенно в энтерпрайзе достаточно низкая. Применимость в специфичных областях — возможно. По больщому счету — СУБД для бедных, так как основнойю плюс — хорошая мастшатбируемость. То есть либо данных не просто много, а очень много (гугл, яндекс) и они однотипные, что даже большие серверы не справляются и все приходтся хранить на множестве больших серверов. Либо бедная компания с хорошим объемом данных, которая хочет создать ХД на копеечных серверах.
Но хороший тюнинг той же терадаты или оракл датабейс позволял реализовать то же хранилище пар ключ-значение с классическим SQL.
Лет через 7-10 эти решения займут свою небольшую нишу, так же, как и иерархические СУБД и ажиотаж спадет.
Масштабируемость — наше все. Попробуйте распределить на тысячи узлов обычную базу данных… И не реплицировать а распределить. И из ключа узнать какая машина хранит нужный кусок?.. Ввести новую машину для хранения пространства ключей от сих до сих? Это как-раз наоборот — СУБД для богатых. А там где данные вмещаются в 1-5 машин… Там это лишнее… Да и реляционная алгебра нужна таки не всем приложениям. Далеко не всем. Вот пример — сервер, который хранит учетки пользователей очень посещаемой игры. На кой там слияния? Проверка целостности? Триггеры? Виды? У него задача — по ID пользователя проверить пароль и отдать нечто, называемое пользователем (структуры данных). И делать это ооочень быстро. Что еще важнее — очень быстро вносить изменения. RDBMS нужны там, где надо выполнять нетривиальные манипуляции с множествами. Для взять-положить абсолютно ни к чему вся эта мишура.
На счет тысяч машин не скажу, но терадата изначально хранит все партицированно по множеству машин (нодам). При этом обеспечивая все фишечки RDBMS: транзакции, первичные ключи, индексы, ссылочные ключи и прочее. Помимо этого так же поддерживает горячую замену вышедшего из строя узла автоматически соседним узлом без потери данных. И это у них с 70-х годов. А учетки с паролями: сколько их? Несколько миллионов? Миллиард? Любая субд справится. Даже большую часть таблицы скорее всего закеширует в RAM и будет отдавать мгновенно без всяких кластеров, банальный индекс по логину.
И все же «партиционирование по нодам» накладывает определенные ограничения и не весь функционал доступен для реляционных СУБД (например join). ???
Почему не доступен? Доступен. В каждой таблице выбирается pimary index (не key) — поле, по которому будет партицироваться таблица. И на мастер-сервере хранится правило распределения (типа если остаток от деления хеша поля на количество серверов = 3, значит искать на сервере X). Если primary index двух связываемых таблиц не совпадает, то записи для связывания будут переноситься между нодами (там специальная высокопроизводительная сеть серверов by-net многие-ко-многим). Так что все джойны доступны, доступные сквозные индексы на таблицу (не только на партицию), рекурсивные запросы в нотации ANSI SQL (что даже Oracle прикрутил совсем недавно). Резервное дублирование данных в специальной области таблицы с других нод для горячего замещения упавшей ноды. Ну и прочий очень интересный функционал.
Не скажите, это далеко не просто мода. Есть множество ситуаций, когда данные из прикладной области не ложатся естественным образом на реляцию и приходится их искуственно туда запихивать. Поэтому и появились решения, такие как документо-ориентированные СУБД, СУБД на графах и т.д. + для кэширования часто используют СУБД типа ключ-значения (в связке с теми же реляционными и не реляционными базами).
Есть, я не говорю, что их нет. Но не так много, как кажется. Теория RDB — это хорошо изученная, имеющая четкое математическое обоснование (теория множеств) и многолетний best practice область. А все эти хадупы, конечно, кому-то нужны. Но применять их надо с осторожностью. Во-первых, удостоверившись, что это действительно лучший способ организации данных, во-вторых, стоит оценивать риски того, что продукт не слишком популярный и молодой. Значит, ограниченный круг специалистов, большая вероятность напороться на проблему впервые. Так же высока вероятность неправильного выбора инструмента или технологии, так как множество ее недостатков еще может быть просто неизвестно.
Ну и если уж зашел вопрос о моде. Вот работает из года в год в крупной богатой компании с большими ИТ-бюджетами ИТ-директор. Он уже купил все SAPы R/3 и BW, все Business Objects и даже datamining, event-based систему мониторинга, электронный документооборот. И что бы ему купить в следующий год? Ведь никто не любит, когда бюджет будущий меньше предыдущего. Да и премии за проекты надо получать. Ну и просто стоять на месте — значит отставать. Хотя бы в глазах акционеров. Так вот, что должен покупать директор? Если вендоры все как один говорят о мобильной отчетности, NoSQL, in-memory и поколоночных базах данных, облачных продуктах (с ними кстати, проблемы — крупная российская компания вряд ли захочет показывать данные «третьей» стороне»). Если взять что-то не слишком популярное, не на слуху, то сложно будет согласовать договор с руководством. А так, заявляешь, что берешь in-memory СУБД, показываешь красивые пресс-релизы, которых множество, восторженные отзывы в Интернете. Руководство дополнительно советуется с коллегами в других компаниях: везде берут похожее. Значит и здесь вопросов меньше будет. А то, что некоторые in-memory пока не поддерживают традиционное транзакционное изменение/вставку/удаление данных — так это же «мелочи». :) Или то, что Oracle при наличии достаточного объема RAM часто используемые данные мог практически полностью кешировать в памяти и не кричал на всех углах о in-memory — тоже.
Господа, а кто-нибудь из присутствующих подобные решения реально использовал? Имею в виду реальные приложения с горизонтальным масштабированием баз данных. Исключая системы, хранящие данные в оперативке (Memcached, Redis, MySQL Cluster). Имеются в виду распределенные системы хранения данных, хранящие данные на дисках, отказоустойчивые. Для хранения больших объемов текстовых данных. Кто что может посоветовать в плане простоты освоения, надежности, простоты добавления и замены машин в пуле и т.д.
Что можете посоветовать?