NoSQL *

ArangoDB мультимодельная (документная и графовая) база данных. К ее положительным сторонам относятся:

• мощный и удобный язык запросов AQL
• JOIN (даже более мощный чем в реляционных базах данных)
• репликация и шардинг
• ACID (в кластере работает только в платной версии)

Из менее существенных, но не менее удобных возможностей:

• нечеткий поиск
• встроенный в базу данных движок микросервисов Foxx
• работа в режиме подписки на изменения в базе данных

Справедливости ради отмечу и недостатки:

• отсутствие ODM
• низкая популярность (в сравнении например с MongoDB)

После анализа возможностей ArangoDB и, в особенности, после преодоления в последних версиях недостатков (таких как резкое падение производительности при превышении размера коллекции доступной оперативной памяти) и появлении новых возможностей (таких как нечеткий поиск) — пришло время испытаний в реальном приложении.

Тестирование производительности HBase с помощью YCSB

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

В Apache Cassandra 4.0 будет новое значение по умолчанию для num_tokens! Звучит как незначительное изменение в CHANGES.txt, но по факту это серьезно повлияет на работу кластера. Как новое значение num_tokens скажется на кластере и его поведении?

От редакции: 27 марта приглашаем на открытую онлайн-конференцию Cassandra Day Russia 2021. В программе доклады и воркшопы. Материалы конференции подойдут как начинающим, так и опытным специалистам.

Apache Cassandra 4.0 приближается к бете (прим. переводчика: на текущий момент уже доступна бета 4, выпущенная в конце декабря 2020), и это первая версия, которая будет поддерживать JDK 11 и более поздних версий. Пользователей Apache Cassandra, очевидно, волнует задержка, так что мы возлагаем большие надежды на ZGC — новый сборщик мусора с низкой задержкой, представленный в JDK 11.

В JDK 14 он был выпущен уже в GA-версии, и нам было очень интересно оценить, насколько он подходит для кластеров Apache Cassandra. Мы хотели сравнить производительность Apache Cassandra 3.11.6 и 4.0 и проверить, подходит ли Shenandoah, сборщик мусора от Red Hat, для продакшена. Спойлер: Cassandra 4.0 значительно лучше по производительности сама по себе, а с новыми сборщиками мусора (ZGC и особенно Shenandoah) будет совсем хорошо.

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

Есть несколько соображений о том, почему стоит поговорить про обмен данными через API на основе SQL/REST/GraphQL, в противовес представлению их в виде типов/объектов:

Однажды, в качестве тестового задания на позицию PHP разработчика была предложена задача реализации сервиса проверки номеров паспортов граждан РФ на предмет нахождения в списке недействительных. Текст задания был лаконичным: «Пользовательская база 10 миллионов, время ответа 1 миллисекунда, аптайм 99%».

Не густо, но попробуем сделать из этого конфетку.

Привет, Хабр! Сегодня будет продолжение темы Кластеризация и классификация больших Текстовых данных с помощью машинного обучения на Java. Данная статья является продолжением первой и второй статьи.

Я – выскочка. По крайней мере, так я себя иногда ощущаю. Закончив второй курс политологии и журналистики в университете, я увидел американский рейтинг профессий по уровню оплаты труда. Журналист в этом рейтинге был на последнем месте, а на первых местах были data scientists и data engineers (политолога в этом списке, почему-то, не было). Я не знал, кто составлял этот список, и понятия не имел, кто такие эти data-челы с первых строк, но он меня впечатлил. Я бросил пить и начал проходить курсы на Coursera, а потом каким-то чудом заполучил студенческую подработку в стартапе. Так я сделал своё «войти в IT».

Когда человек, не имеющий университетской подготовки, пытается начать программировать, то он чувствует себя несчастным, который, увидев из окна солнце, вышел на улицу и попал под неожиданный в столь прекрасный день град: шаблоны проектирования, функции, классы, ООП, инкапсуляция, протоколы, потоки, ACID… Хочется прокричать, как Виктор Фёдорович в своё время:

Мы хотели реализовать пагинацию и для этого нам пришлось форкнуть диалект для Hibernate.

Эта статья о следующем эволюционном шаге в развитии систем обработки данных. Тема амбициозная, поэтому расскажу сначала немного о себе. Вот уже больше 10 лет я работаю над проектами в области CRDT и синхронизации данных. За это время успел поработать на университеты, стартапы YCombinator и известные международные компании. Мой проект последние три года – Replicated Object Notation, новый формат представления данных, сочетающий возможности объектной нотации (как JSON или YAML), сетевого протокола и оплога/бинлога. Вы могли слышать про другие проекты, работающие в том же направлении, например, Datanet, Automerge и другие. Также вы могли читать Local-first software, это наиболее полный манифест данного направления Computer Science. Авторы - замечательный коллектив Ink&Switch, включая широко нам известного по "Книге с Кабанчиком" М.Клеппманна. Или вы, возможно, слушали мои выступления по этой теме на различных конференциях.

Идеи этой статьи перекликаются с тем, что пишет последние годы Pat Helland: Immutability Changes Everything и др. Они смежны с проектами IPFS и DAT, к которым я имею отношение.

Итак. Классические БД выстроены на линейном логе операций (WAL). От этого лога выстроены транзакции, от него же выстроена репликация master-slave. Теория репликации с линейным логом написана ещё в начале 1980-х с участием небезызвестного Л. Лампорта. В классических legacy системах с одной большой центральной базой данных всё это работает хорошо. Так работают Oracle, Postresql, MySQL, DB2 и прочие классические SQL БД. Так работают и многие key-value БД, например, LevelDB/RocksDB.

Но линеаризация не масштабируется. Когда система становится распределённой, всё это начинает ломаться. Образно говоря, линейная система – это что-то вроде греческой фаланги. Нужно, чтобы все шли ровно, а для этого хорошо, чтобы земля была везде ровной. Так получается не всегда: где-то электричество отключили, а где-то сеть медленная. Хотя в системе Google Spanner и было показано, что с достаточно большим бюджетом землю можно сделать ровной абсолютно везде, мы всё же отметим, что Google тоже бывает отключается целиком по совершенно смешным причинам.

Привет, Хабр! Сегодня будет продолжение темы Кластеризация и классификация больших Текстовых данных с помощью машинного обучения на Java. Данная статья является продолжением первой статьи.

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

• Частичная или полная автоматизация задачи кластеризации и классификации больших данных, а именно текстовых данных.
• Применение алгоритмов машинного обучение “без учителя” (кластеризация) и “с учителем” (классификация).
• Анализ текущих решений задач.

1. Разработка и применение алгоритмов и методов обработки естественного языка.
2. Разработка и применение методов кластеризации для определения кластерных групп входных документов.
3. Применение методов классификации для определения предмета каждых кластерных групп.
4. Разработка веб-интерфейса на основе Java Vaadin

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

1. Обработка естественного языка.
   
   1. токенизация;
   2. лемматизация;
   3. стоп-листинг;
   4. частота слов;
   
   
2. Методы кластеризации.
   TF-IDF ;
   SVD;
   нахождение кластерных групп;
   
3. Методы классификации – Aylien API.

Некоторое время назад на горизонте возникла и начала набирать популярность платформа Apache Ignite. Вычисления in-memory — это скорость, а значит, скорость должна быть обеспечена на всех этапах работы, особенно при загрузке данных.

Под катом находится описание способа быстрой загрузки данных из реляционной таблицы в распределенный кластер Apache Ignite. Описана предобработка SQL query result set на клиентском узле кластера и распределение данных по кластеру с помощью задания map-reduce. Описаны кеши и соответствующие реляционные таблицы, показано, как создать пользовательский объект из строки таблицы и как применить ComputeTaskAdapter для быстрого размещения созданных объектов. Весь код полностью можно увидеть в репозитории FastDataLoad.

ODM - Object Document Mapper - используется преимущественно для доступа к документоориенриирвоанным базам данных, к которым относятся MongoDB, CouchDB, ArangoDB, OrientDB (последние две базы данных гибридные) и некоторые другие.

Прежде чем перейти к рассмотрению вопроса, озвученного в названии сообщения, приведу статистику скачивания пакетов из публичного регистра npm.