Мне любопытно, делал ли кто-нибудь тесты доступа к данным в базах данных NoSQL по сравнению с Oracle (в частности, я говорю об Oracle RAC)? Проект требует работы не менее чем с 10 млн+ записей, поиск среди них (но не обязательно в режиме реального времени), чтение очень важно для скорости, а также очень важно гарантировать высокую доступность и надежность (не могу потерять записи!!!) Я сам вижу, как, скажем, Cassandra/MongoDB может лучше подойти (поскольку хранилище значений ключа обеспечит более быстрое чтение, чем SQL, когда вы просматриваете 10 миль записей), но мне трудно сформулировать все красиво. Любые ссылки? Предложения? Отверстия от пуль? Спасибо!
Oracle (RAC) против NoSQL
comment
Мой трехлетний ноутбук отлично обрабатывает 10 миллионов строк при стандартной установке Oracle XE.
- person Ronnis schedule 10.02.2011
comment
В 2012 году 10 млн записей — это не такой уж большой объем данных. Как указано ниже, 2,5 ГБ будут очень легко размещаться в памяти любой современной системы.
- person Art Taylor schedule 20.04.2012
Ответы (2)
10 миллионов записей. Предположим, 250 байт на запись. Это около 2,5 Гб данных, что вполне соответствует возможностям обычного настольного ПК/ноутбука. Объемы данных незначительны (если только каждая запись не имеет размер в мегабайтах, например изображение или звук).
Вам действительно нужно поговорить об объемах транзакций (разделенных на чтение и запись) и о том, что вы считаете HA. HA только для чтения проще по сравнению с HA «чтение-запись». Может быть тривиально реплицировать набор данных только для чтения на несколько серверов в разных географических точках и распределить на них рабочую нагрузку запросов.
Гораздо сложнее масштабировать большую рабочую нагрузку обновлений, поэтому вы часто слышите о том, что системы выходят из строя, когда выпускаются билеты на большой концерт. Проще говоря, существует фиксированное количество мест, и у вас не может быть десяти дублированных систем, каждая из которых продает то, что, по их думанию, доступно. Должен быть единственный источник правды, что означает узкое место (и, возможно, единую точку отказа).
Что касается высокой доступности, RAC — это технология общего хранилища, которая обычно означает, что ваши узлы RAC находятся в непосредственной близости. Это может сделать их уязвимыми для локальных событий, таких как пожар в здании или поломка телекоммуникаций. Data Guard — это технология Oracle, связанная с удаленной репликацией и аварийным переключением.
person
Gary Myers
schedule
10.02.2011
10 миллионов записей, но они ожидали роста на 30-50% каждые две недели. Интересно, в какой момент Oracle станет медленнее? Я пытаюсь найти какие-либо тесты, если мы собираемся использовать Oracle RAC в качестве хранилища ключ-значение по сравнению с Cassandra/MongoDB/и т. д. Кто обеспечивает лучшую производительность? Меня больше интересует чтение;
- person alexeypro; 10.02.2011
Меня также интересуют любые официальные документы по этому вопросу. Хотя мои требования на порядок больше. Проблема с уходом бизнеса от Oracle заключается в брендинге Oracle. Любые примеры из реального мира были бы замечательными.
- person Andrew T Finnell; 12.03.2012
В основном, когда вы сравниваете NoSQL и SQL, вы должны понимать очень важную разницу между ними. Данные в NoSQL могут быть несовместимы с точки зрения стоимости для достижения высокой доступности.
Что я подразумеваю под непоследовательным? Это зависит от времени, но обычно около 3-5 секунд для распространения данных по узлам. База данных NoSQL предоставляет механизм для управления и устранения этого, но если вы хотите, чтобы все ваши данные были согласованы в режиме реального времени, вы просто используете классический SQL, такой как Oracle RAC.
Возвращаясь к сравнению скорости: просто несопоставимо, какой из них быстрее, потому что он зависит от таких факторов, как сетевая инфраструктура, вычислительная мощность, модель базы данных и т. д. Но важно то, что в какой-то момент вы можете достичь момента, когда SQL <сильно>экономически неэффективен в обслуживании, и вам придется переключиться на NoSQL.
person
masterspambot
schedule
18.02.2013
