Практический пример для каждого типа базы данных (реальные случаи)

Ответ 1

Я нашел две впечатляющие статьи по этому вопросу.

Все кредиты highscalability.com. Информация транскрибируется с этих URL-адресов.

http://highscalability.com/blog/2011/6/20/35-use-cases-for-choosing-your-next-nosql-database.html

http://highscalability.com/blog/2010/12/6/what-the-heck-are-you-actually-using-nosql-for.html

Если ваши потребности в приложении...

• сложные транзакции, потому что вы не можете позволить себе потерять данные, или если вам нужна простая модель программирования транзакций, посмотрите на реляционную или грид-базу данных.

• Пример: система инвентаризации, которая может потребовать полной ACID. Я был очень недоволен, когда я купил продукт, и они сказали, что позже их нет в наличии. Мне не нужна компенсационная сделка. Я хотел свой товар!

• для масштабирования, тогда NoSQL или SQL могут работать. Посмотрите на системы, которые поддерживают масштабирование, разбиение на разделы, добавление и удаление машин, балансировку нагрузки, автоматическое масштабирование и балансировку и отказоустойчивость.

• всегда иметь возможность писать в базу данных, потому что вам нужна высокая доступность, а затем посмотрите на Bigtable Clones, которые имеют конечную консистенцию.

• для обработки большого количества небольших непрерывных операций чтения и записи, которые могут быть неустойчивыми, а затем посмотрите на документ или значение ключа или базы данных, предлагающие быстрый доступ к памяти. Также рассмотрите SSD.

• для реализации операций в социальной сети, тогда вам может понадобиться база данных Graph или вторая, такая база данных, как Riak, поддерживающая отношения. Для небольших наборов данных может быть достаточной реляционная база данных с простой связью SQL. Операции набора и списка Redis также могут работать.

• использовать широкий спектр шаблонов доступа и типов данных, а затем посмотреть базу данных документа, они, как правило, гибкие и хорошо работают.

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

• объединить несколько центров обработки данных, а затем посмотреть на Bigtable Clones и другие продукты, предлагающие распределенную опцию, которая может обрабатывать длительные задержки и терпима к разделам.

• для создания приложений CRUD, а затем просмотрите базу данных Document, они упрощают доступ к сложным данным без соединений.

• встроенный поиск, затем посмотрите на Riak.

• для работы с структурами данных, такими как списки, наборы, очереди, публикация-подписка, а затем посмотрите на Redis. Полезно для распределенных блокировок, закрытых журналов и многое другое.

• дружелюбие программиста в форме дружественных программисту типов данных, таких как JSON, HTTP, REST, Javascript, затем сначала посмотрите на базы данных Документов, а затем на базы данных с ключевыми значениями.

• транзакции в сочетании с материализованными представлениями для в режиме реального времени, а затем посмотрите на VoltDB. Отлично подходит для развертывания данных и временного окна.

• поддержка уровня предприятия и SLA, а затем найдите продукт, который станет точкой обслуживания на этом рынке. Пример Membase.

• записывать непрерывные потоки данных, которые могут вообще не иметь никаких гарантий согласованности, а затем смотреть на Bigtable Clones, потому что они обычно работают с распределенными файловыми системами, которые могут обрабатывать много записей.

• чтобы быть максимально простым, чтобы работать, ищите решение Host или PaaS, потому что они будут выполнять всю работу за вас.

• для продажи корпоративным клиентам, тогда рассмотрим реляционную базу данных, поскольку они используются для реляционных технологий.

• динамически строить отношения между объектами, имеющими динамические свойства, затем рассмотрим базу данных графиков, потому что часто они не требуют схемы, а модели могут быть построены постепенно с помощью программирования.

• для поддержки больших носителей, затем посмотрите службы хранения, такие как S3. Системы NoSQL, как правило, не обрабатывают большие BLOBS, хотя MongoDB имеет файловую службу.

• массовая загрузка много данных быстро и эффективно, а затем поиск продукта поддерживает этот сценарий. Большинство не будет, потому что они не поддерживают массовые операции.

• более простой путь обновлениязатем используйте систему флюидных схем, такую ​​как база данных документов или база данных ключа, поскольку она поддерживает необязательные поля, добавление полей и удаление полей без необходимости создания всей схемы миграции схемы.

• реализовать ограничения целостности, затем выбрать базу данных, поддерживающую SQL DDL, реализовать их в хранимых процедурах или реализовать их в коде приложения.

• глубокая глубина соединения использует графическую базу данных, потому что они поддерживают быстро растущую навигацию между объектами.

• перемещать поведение рядом с данными, поэтому данные не должны перемещаться по сети, а затем просматривать хранимые процедуры того или иного типа. Они могут быть найдены в реляционных, сетчатых, документарных и даже базовых базах данных.

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

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

• типы данных флюидов, потому что ваши данные не являются табличными по своему характеру или требуют гибкого количества столбцов или имеют сложную структуру или зависят от пользователя (или что-то еще), а затем посмотрите на Документы, базы данных Key-value и Bigtable Clone. Каждый из них имеет большую гибкость в своих типах данных.

• другие бизнес-единицы выполнят быстрые реляционные запросы, поэтому вам не нужно переопределять все, а затем использовать базу данных, поддерживающую SQL.

• работать в облаке и автоматически использовать преимущества облачных функций, тогда мы, возможно, еще не были там.

• поддержка вторичных индексов, чтобы вы могли искать данные разными ключами, а затем просматривать реляционные базы данных и новую поддержку вторичных индексов Cassandra.

• создает постоянно растущий набор данных (действительно BigData), к которым редко обращаются, а затем смотрите на Bigtable Clone, который будет распространять данные по распределенной файловой системе.

• интегрироваться с другими службами, затем проверьте, предоставила ли база данных какую-то функцию синхронизации записи, чтобы вы могли записывать изменения в базе данных и передавать их в другие системы, чтобы обеспечить согласованность.

• отказоустойчивость проверяет, как долговечные записи находятся в случаях сбоев питания, разделов и других сценариев сбоев.

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

• для работы с мобильной платформой , посмотрите на кушетку CouchDB/Mobile.

Общие случаи использования (NoSQL)

• Bigness. NoSQL рассматривается как ключевая часть нового стека данных: большие данные, большое количество пользователей, большое количество компьютеров, большие сети поставок, большая наука и т.д. Когда что-то становится настолько массивным, что оно должно быть широко распространено, NoSQL существует, хотя не все системы NoSQL нацелены на большие. Bigness может быть во многих разных измерениях, а не просто использовать много дискового пространства.

• Массивная производительность записи. Это, вероятно, каноническое использование, основанное на влиянии Google. Большой объем. Facebook должен хранить 135 миллиардов сообщений в месяц. Например, у Twitter есть проблема хранения 7 ТБ/данных в день с перспективой удвоения этого требования несколько раз в год. Это слишком большие данные, чтобы соответствовать одной проблеме node. При 80 Мбайт/с требуется хранить 7 ТБ, поэтому записи должны быть распределены по кластеру, что подразумевает доступ к ключам, MapReduce, репликацию, отказоустойчивость, проблемы согласованности и все остальное. Для более быстрой записи можно использовать системы памяти.

• Быстрый доступ к ключевому значению.. Это, вероятно, вторая, наиболее цитируемая добродетель NoSQL в общем наборе разума. Когда латентность важна, трудно бить хэширование по ключу и считывать значение непосредственно из памяти или всего лишь одним диском. Не каждый продукт NoSQL - это быстрый доступ, некоторые - о надежности, например. но то, что люди хотели в течение долгого времени, было лучше memcached, и многие системы NoSQL предлагают это.

• Гибкая схема и гибкие типы данных. Продукты NoSQL поддерживают целый ряд новых типов данных, и это основная область инноваций в NoSQL. У нас есть: столбцы-ориентированные, графические, расширенные структуры данных, документально-ориентированные и ключевые значения. Сложные объекты могут быть легко сохранены без большого количества картографирования. Разработчики любят избегать сложных схем и структур ORM. Отсутствие структуры обеспечивает большую гибкость. У нас также есть совместимые с программами и программистами совместимые типы данных JSON.

• Миграция схемы.. Скромность облегчает работу с миграциями схем без особого беспокойства. Схемы в некотором смысле динамичны, потому что они навязаны приложением во время выполнения, поэтому разные части приложения могут иметь другое представление схемы.

• Создать доступность.. Что делать, если ваши записи не нужны? Затем мы можем перейти к разделению, CAP, возможной последовательности и всему этому джазу.

• Простая ремонтопригодность, администрирование и операции.. Это очень специфичный продукт, но многие производители NoSQL пытаются получить усыновление, упростив для разработчиков их принятие. Они тратят много усилий на простоту использования, минимальное администрирование и автоматические операции. Это может привести к снижению операционных издержек, поскольку специальный код не должен быть написан для масштабирования системы, которая никогда не предназначалась для использования таким образом.

• Нет единой точки отказа. Не каждый продукт выполняет это, но мы видим определенную конвергенцию относительно легко настраиваемой и управляемой высокой доступности с автоматической балансировкой нагрузки и размером кластеров. Идеальный партнер с облаками.

• Обычно доступные параллельные вычисления. Мы видим, что MapReduce запекается в продукты, что делает параллельные вычисления чем-то, что будет нормальной частью разработки в будущем.

• Простота использования программы. Доступ к вашим данным должен быть простым. Хотя реляционная модель интуитивно понятна для конечных пользователей, таких как бухгалтеры, она не очень интуитивно понятна для разработчиков. Программисты grok-ключи, значения, JSON, хранимые процедуры Javascript, HTTP и т.д. NoSQL предназначен для программистов. Это управляемый переворот. Ответ на проблему с базой данных не всегда может заключаться в том, чтобы нанять действительно знающего администратора баз данных, правильно настроить схему, немного денормализовать и т.д., Программисты предпочли бы систему, чтобы они могли сделать работу для себя. Не должно быть так сложно сделать продукт. Деньги являются частью проблемы. Если это стоит много, чтобы масштабировать продукт, тогда вы не пойдете с более дешевым продуктом, который вы контролируете, тем проще в использовании и тем легче масштабировать?

• Используйте правильную модель данных для правильной проблемы. Различные модели данных используются для решения различных проблем. Было приложено много усилий, например, для того, чтобы скопировать операции графа в реляционную модель, но она не работает. Разве не лучше решить задачу графа в базе данных графа? Теперь мы видим общую стратегию поиска наилучшего соответствия между проблемой и решением.

• Избегайте попадания в стену. Многие проекты затрагивают какой-то тип стены в своем проекте. Они исчерпали все возможности, чтобы сделать их системный масштаб или выполнить правильно, и задаются вопросом, что дальше? Удовлетворение выбора продукта и подхода, который может перепрыгнуть через стену путем линейного масштабирования с использованием добавочно добавленных ресурсов. В свое время это было невозможно. Для этого потребовалось изготовленное на заказ все, но это изменилось. Теперь мы видим доступные готовые продукты, которые проект может легко принять.

• Поддержка распределенных систем. Не все беспокоятся о масштабах или производительности сверх того, что может быть достигнуто системами без NoSQL. Им нужна распределенная система, которая может охватывать датацентры при обработке сценариев сбоев без икоты. Системы NoSQL, поскольку они сосредоточены на масштабе, имеют тенденцию использовать разделы, обычно не используют жесткие строгие протоколы согласованности и поэтому имеют хорошие возможности для работы в распределенных сценариях.

• Перестраиваемые компромиссы CAP.Системы NoSQL - это, как правило, единственные продукты с "слайдером" для выбора места, где они хотят приземлиться в спектре CAP. Реляционные базы данных выбирают сильную согласованность, что означает, что они не могут терпеть отказ раздела. В конечном итоге это бизнес-решение, и его следует решать в каждом конкретном случае. Ваше приложение даже заботится о последовательности? Есть несколько капель в порядке? Требуется ли ваше приложение сильной или слабой последовательности? Является ли доступность более важной или последовательной? Будет ли более дорогостоящим, чем неправильным? Приятно иметь продукты, которые дают вам выбор.

• Более конкретные случаи использования

• Управление большими потоками данных без транзакций: журналы Apache, журналы приложений, журналы MySQL, обратные ссылки и т.д.

• Синхронизация онлайновых и автономных данных. Это ниша CouchDB нацелена.

• Быстрое время отклика при всех нагрузках.

• Избегать тяжелых объединений, когда загрузка запроса для сложных объединений становится слишком большой для СУБД.

• Мягкие системы реального времени, где низкая латентность имеет решающее значение. Игры - один из примеров.

• Приложения, в которых необходимо поддерживать большое количество различных шаблонов записи, чтения, запроса и согласованности. Существуют системы, оптимизированные для 50% чтения 50% записи, 95% записи или 95% чтения. Приложения только для чтения, требующие экстремальной скорости и отказоустойчивости, простые запросы и могут переносить слегка устаревшие данные. Приложения, требующие умеренной производительности, доступа для чтения/записи, простых запросов, полностью авторитетных данных. Приложение только для чтения, требующее сложных запросов.

• Баланс нагрузки для учета концентрации данных и использования и для поддержания работы микропроцессоров.

• Вставки, обновления и запросы в режиме реального времени.

• Иерархические данные, такие как обсуждение с резьбой и взрыв деталей.

• Создание динамической таблицы.

• Двухуровневые приложения, где данные с низкой задержкой становятся доступными через быстрый интерфейс NoSQL, но сами данные могут быть рассчитаны и обновлены приложениями Hadoop с высокой задержкой или другими приложениями с низким приоритетом.

• Последовательное чтение данных. Необходимо выбрать правильную базовую модель хранения данных. B-дерево может быть не лучшей моделью для последовательных чтений.

• Отрезание части обслуживания, которая может потребовать лучшей производительности/масштабируемости на собственной системе. Например, пользовательские логины могут нуждаться в высокой производительности, и эта функция может использовать выделенный сервис для достижения этих целей.

• Кэширование. Высокий уровень кэширования для веб-сайтов и других приложений. Пример - это кеш для системы агрегирования данных, используемой Большим адронным коллайдером. Голосование.

• Счетчики просмотров в режиме реального времени.

• Регистрация пользователя, профиль и данные сеанса.

• Документы, управление каталогом и системы управления контентом.. Этим облегчается возможность хранения сложных документов, а целые, а не организованные как реляционные таблицы. Подобная логика применяется к инвентарю, тележкам и другим структурированным типам данных.

• Архивирование. Хранение большого непрерывного потока данных, который по-прежнему доступен в режиме онлайн. Документированные базы данных с гибкой схемой, которая со временем может обрабатывать изменения схемы.

• Аналитика. Используйте MapReduce, Hive или Pig для выполнения аналитических запросов и масштабируемых систем, которые поддерживают высокую нагрузку на запись.

• Работа с гетерогенными типами данных, например, с разными типами носителей на общем уровне.

• Встроенные системы. Они не хотят накладных расходов SQL и серверов, поэтому они используют что-то более простое для хранения.

• Игра "на рынке", где вы владеете зданиями в городе. Вы хотите, чтобы список из списка людей быстро появился, поэтому вы разбиваете столбец владельца таблицы зданий, чтобы выбор был однораздельным. Но когда кто-то покупает здание кого-то другого, вы обновляете колонку владельца вместе с ценой.

• JPL использует SimpleDB для хранения атрибутов плана ровера. Ссылки хранятся в полном блочном блоке в S3.

• Федеральные правоохранительные органы отслеживают американцев в режиме реального времени с использованием кредитных карт, карт лояльности и резервирования поездок.

• Обнаружение мошенничества путем сравнения транзакций с известными шаблонами в режиме реального времени.

• Помогает диагностировать типологию опухолей путем интеграции истории каждого пациента. База данных с памятью для ситуаций с высоким уровнем обновления, например, веб-сайт, на котором отображается каждое "последнее активное" время (возможно, для чата). Если пользователи выполняют некоторую активность один раз каждые 30 секунд, то вы в значительной степени будете на пределе с примерно 5000 одновременных пользователей. Обработка низкочастотных многораздельных запросов с использованием материализованных представлений при продолжении обработки высокочастотных потоковых данных.

• очереди приоритетов.

• Выполнение расчетов по кэшированным данным с использованием дружественного к программе интерфейса без необходимости проходить через ORM.

• Уникальный большой набор данных с использованием простых столбцов значения ключа.

• Чтобы быстро выполнять запрос, значения могут быть свернуты на разные временные фрагменты.

• Вычисление пересечения двух массивных множеств, где объединение будет слишком медленным.

• Временная шкала ala Twitter.

Ответ 2

Этот вопрос почти невозможно ответить из-за общности. Я думаю, вы ищете какую-то легкую проблему с ответом = решение. Проблема в том, что каждая "проблема" становится все более уникальной, поскольку она становится бизнесом.

Что вы называете социальной сетью? Twitter? Facebook? LinkedIn? Переполнение стека? Все они используют разные решения для разных частей, и может существовать множество решений, использующих полиглотный подход. У Twitter есть график, похожий на концепт, но есть только 1 градус связи, последователи и следующие. LinkedIn, с другой стороны, процветает, показывая, как люди связаны за пределами первой степени. Это две разные потребности в обработке и данных, но оба являются "социальными сетями".

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

Если вы выполняете машинное обучение поверх данных журнала, которые вы собираете, вы можете интегрировать Hadoop с Hive или Pig или Spark/Shark. Или вы можете сделать лямбда-архитектуру и использовать множество разных систем со Storm.

Если вы делаете открытие через граф, например, запросы, выходящие за пределы вершин 2-й степени, а также фильтрацию по свойствам краев, вы, вероятно, будете рассматривать базы данных графов поверх основного хранилища. Однако базы данных графов не являются хорошим выбором для хранилища сеансов или в качестве хранилищ общего назначения, поэтому для решения проблемы вам понадобится решение polyglot.

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