Translate

неділю, 24 липня 2016 р.

Redis Basics

Redis (REmote DIctionary Server) - високопродуктивна нереляційна база даних типу ключ-значення, розробку якої наразі фінансує Redis Labs, а раніше - Pivotal Software та VMware. Це програмне забезпечення з відкритим сирцевим кодом написане на мові C. Redis досить зрілий проект і має набір готових біндингів до різноманітних мов програмування.

Redis дуже часто розглядають як заміну Memcached, адже доступ до значень також відбувається по ключу. Проте він, на відміну від останнього, володіє купою переваг, серед яких:
  • Можливість з певною частотою зберігати дані з оперативної в постійну пам'ять. Тож у разі падіння демона дані будуть наявні після рестарту. У останніх версіях Redis є можливість вести лог операцій запису. Щось на зразок бінлогу в MySQL.
  • Більше можливих типів даних, котрі можуть зберігатись. Redis, окрім рядків (strings), підтримує збереження масивів (lists), хеш-таблиць (hash tables), множин (sets), сортованих множин (sorted sets), масиви біт (bitmaps) та HyperLogLog. Останні по-суті базуються на рядках (strings), які мають свою власну семантику. Детальніше про них далі.
  • Реплікація (built-in), кластеризація (Redis Sentinel, Redis Cluster), шардинг (Redis Cluster), висока доступність (Redis Sentinel, Redis Cluster). Цього всього немає в ванільному Memcached, але воно так необхідне при створенні інфраструктур високої доступності.
  • Підтримка транзакцій. Команди можуть бути виконані групою, і у разі невиконання однієї із них - відбудеться повернення на попередній стан. Також команди можна виконувати пакетами (виконуємо пачку команд, потім отримуємо пачку результатів).
  • Підтримка механізму publish/subscribe. Програми, що використовують Redis, можуть створювати іменовані канали і додавати в них повідомлення, а інші програми, відповідно, можуть забирати дані з таких каналів. У моєму розумінні, це щось схоже на черги в RabbitMQ.

суботу, 9 липня 2016 р.

Marvel. Monitoring Plugin for Elasticsearch

Півроку тому я писав статтю про Elasticsearch, його кластеризацію, основи роботи. Сьогодні ж поговоримо про способи його моніторингу, а саме установку Marvel. Одразу скажу, що він коштує достатньо космічних сум (проте безкоштовний для використання в DEV-середовищах) і не кожен бізнес може його дозволити собі.

Враховуючи ці ціни, можливо, краще спробувати відкриті альтернативи на кшталт Kopf чи Elasticsearch-head, про котрі я також згадував у власній статті. Проте, ймовірно, вони менш функціональні і призначені скоріше для моніторингу кластерних ресурсів: шардів, реплік, стану кластеру.

Опишу трохи майбутню тестову архітектуру. Розробники з Elastic рекомендують для Prod-середовищ виділяти окремий сервер для Marvel, адже останній логує свої сервісні дані та проводить певні розрахунки, котрі можуть впливати на завантаження самого Elasticsearch. Тому наша інсталяція складатиметься з вузлу Elasticsearch + Marvel-agent, котрий надсилатиме необхідні сервісні дані до іншого вузлу Elasticsearch, котрий буде зберігати їх локально, а Kibana та Marvel plugin, що будуть встановлені тут же, відображатимуть це все.


Установимо oracle-java8-jdk на обидва вузла кластера:

# add-apt-repository ppa:webupd8team/java
# aptitude update
# aptitude install oracle-java8-installer
# update-java-alternatives -s java-8-oracle

# java -version
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)