NoSQL *

Говорят, в жизни все стоит попробовать хотя бы раз. И если вы привыкли работать с реляционными СУБД, то познакомиться на практике с NoSQL стоит в первую очередь хотя бы для общего развития. Сейчас в силу бурного развития этой технологии очень много противоречивых мнений и горячих споров на эту тему, что особенно подогревает интерес.
Если вникнуть в суть всех этих споров, то можно увидеть, что они возникают из-за неправильного подхода. Те, кто использует NoSQL базы именно там, где они нужны, довольны и получают от данного решения все его плюсы. А экспериментаторы, уповающие на данную технологию как панацею там, где она не применима вовсе, испытывают разочарование, потеряв сильные стороны реляционных баз без приобретения весомых выгод.

Я расскажу про наш опыт внедрения решения, основанного на СУБД Cassandra: с чем пришлось столкнуться, как выкручивались из трудных ситуаций, удалось ли нам получить выигрыш от использования NoSQL и где пришлось вложить дополнительные усилия/средства.
Исходная задача — это построение системы, записывающей звонки в некое хранилище.

Принцип действия системы следующий. На вход приходят файлы с определенной структурой, описывающей структуру вызова. Затем приложение обеспечивает сохранение этой структуры в соответствующие колонки. В дальнейшем сохраненные вызовы используются – для отображения информации по потреблению трафика для абонентов (начисления, звонки, история баланса).

Почему выбрали Кассандру вполне понятно — она пишет как пулемет, легко масштабируема, отказоустойчива.

Для локальной отладки сервиса мне понадобилось установить Apache Cassandra на Windows 10. Нормальный установщик был только у компании DataStax, но они прекратили его поддерживать.

В данной статье я опишу, как установить Apache Cassandra на Windows в виде сервиса.

Запись об этом появилась в блоге AWS в начале августа. Эталонная реализация выложена на GitHub.

Почему это важно?

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

Современные информационные системы достаточно сложны. Не в последнюю очередь их сложность обусловлена сложностью обрабатываемых в них данных. Сложность же данных зачастую заключается в многообразии используемых моделей данных. Так, например, когда данные становятся «большими», одной из доставляющих неудобства характеристик считается не только их объем («volume»), но и их разнообразие («variety»).

Если вы пока не находите изъяна в рассуждениях, то читайте дальше.

Реляционная модель потеряла свою исключительность

Требования функциональности и структурированности баз данных (БД), наиболее полно реализованные в реляционных системах, сейчас находятся под давлением новых требований.

Первая проблема – низкая эффективность для больших данных (big data). Источниками больших данных являются социальные сети, системы видеонаблюдения, пространственные сенсоры, биллинг и т.п. Реляционная БД (РБД) хорошо работает, если схема данных точно определена заранее, до запуска прикладного приложения. Но большие данные по своей сути трудно поддаются структурированию на этапе проектирования БД. Только по мере сбора информации, постепенно, ее структура проявляется более очевидно.

Второе – поиск, вычисление запросов в РБД с таблицами огромных размеров – это задача высокой алгоритмической сложности. Использование индексирования и хеширования хорошо работает в более-менее статичных РБД, которые в значительной степени заполняются еще до запуска системы в эксплуатацию.

Мы — отдел большой компании, развивающий важную систему на Java SE / MS SQL / db4o. За несколько лет проект перешел от опытного образца к промышленной эксплуатации и db4o превратилась в тормоз расчета, захотелось перейти с db4o на современную noSQL-технологию. Пробы и ошибки завели далеко от первоначального замысла — от db4o отказаться удалось, но ценой компромисса. Под катом размышления и подробности реализации.

Привет, Хабр. Не так давно для одного моего проекта понадобилась встраиваемая база данных, которая бы хранила элементы в виде ключ-значение, обеспечивала поддержку транзакций, и, опционально, шифровала данные. После непродолжительных поисков, я наткнулся на проект Berkeley DB. Кроме нужных мне возможностей, эта БД предоставляет STL-совместимый интерфейс, который позволяет работать с базой данных, как с обычным (почти обычным) STL-контейнером. Собственно про этот интерфейс речь пойдет ниже.

Поиск в корпоративной информационной системе — уже от самой этой фразы вязнет во рту. Хорошо если он вообще есть, о положительном user experience можно даже не задумываться. Как перевернуть отношение пользователей, избалованных поисковыми системами, и создать быстрый, точный, понимающий с полуслова продукт? Надо взять хороший кусок Elasticsearch, горсть интеллектуальных сервисов и замешать их по этому гайду.

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

При этом сама фраза «Умный поиск» уже превратилась в баззворд и используется к месту и нет. Что же такого должна делать поисковая система, чтобы её можно было считать умной? Ультимативно это можно описать как выдачу результата, который на самом деле нужен пользователю, даже если этот результат не совсем соответствует тексту запроса. Популярные поисковые системы вроде Google и Яндекс идут дальше и не просто находят нужную информацию, а напрямую отвечают на вопросы пользователя.

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

Хочу представить публике фрагмент вот этой недавно вышедшей книги:

Онтологическое моделирование предприятий: методы и технологии [Текст]: монография / [С. В. Горшков, С. С. Кралин и др.; отв. ред. С. В. Горшков]. — Екатеринбург: Изд-во Уральского ун-та, 2019. — 234 с.: ил., табл.; 20 см. — Авт. указаны на обороте тит. с. — Библиогр. в конце гл. — ISBN 978-5-7996-2580-1: 200 экз.

Цель выкладки этого фрагмента на Хабре троякая:

• Собрать вопросы и замечания, чтобы учесть их при включении этого текста в переработанном виде в другие издания.
• Внести дополнения, не очень совместимые с форматом печатной монографии: злободневные примечания (ниже они под спойлерами) и гиперссылки; а также внести исправления (ниже они никак не выделены).
• Многие адепты Semantic Web и Linked Data до сих пор считают, что их круг столь узок в основном потому, что широкой публике все еще по-хорошему не объяснили, что же это такое — Semantic Web и Linked Data. Автор фрагмента, хоть к этому кругу и принадлежит, такого мнения не придерживается, но, тем не менее, считает себя обязанным сделать еще одну попытку.

Semantic Web и Linked Data подобны ближнему космосу: жизни там нет. Чтобы отправиться туда на более-менее длительный срок… ну, не знаю, что говорили вам в детстве в ответ на «хочу стать космонавтом». Но понаблюдать за происходящим можно и находясь на Земле; стать астрономом-любителем или даже профессионалом гораздо проще.

В статье речь пойдет о свежих, не старее нескольких месяцев, трендах из мира RDF-хранилищ. Метафора в первом абзаце была навеяна вот этой эпических размеров рекламной картинкой.

Работаете с NoSQL-хранилищем Apache Cassandra?