img2web

Micro-service of online image microblogs

---

Dependencies

1. cassandra.so
2. libuv.so
3. all deb-packages fastcgi-daemon Собирать через make

img2web REST API:

INTERFACE

REQUEST

• URL: /feed
• METHOD: GET
• PARAMS: page_number, login
• Примечание: page_number - некое число 0 .... N - пользователю будут показаны изображения в промежутке: (page_number * 10, page_number * 10 + 10) // 10 изображений на страницу

RESPONSE

• Content-Type: application/json
• Code: Success - 200 OK
• Body if success: {[{"login" : login1, image_binary_format" : image_binary_format1}, {"login" : login2, image_binary_format" : image_binary_format2}... ]}

-------- REQUEST

• URL: /users // возвращает логины всех, когда либо логинившихся пользователей
• METHOD: GET

RESPONSE

• Content-Type: application/json
• Code: Success - 200
• Body if success: {[{"login": usr_login}, ... ]}

-------- REQUEST

• URL: /subscribe // добавлять в ленту пользователя с логином login записи пользователя username
• METHOD: POST
• PARAMS: login, username

RESPONSE

• Content-Type: plain/text
• Code: Success - 200 FAIL - 434 // login or username does not exist

-------- REQUEST

• URL: /post
• METHOD: POST
• PARAMS: login, image_binary_format

RESPONSE

• Content-Type: application/json
• Code: Success - 200 FAIL - 434 Incorrect login

-------- CAP =============== Про CAP теорему: Для системы обмена картинками консистентность не столь важна как доступность. Поэтому в первую очередь это AP система. В связи с такой направленностью была выбрана Cassandra - в стандартной конфигурации это AP система с приятными бонусами в духе Partiotion Key (позволяет задавать способ разбиения изображений по кластерам, например, с привязкой по географии). Особенностью Cassandra являются быстрые операции вставки (вот поэтому в неё часто пишут логи) - т.е. вставка картинок (особенно с учётом реализации структуры бд) - довольно эффективная операция. Т.к. мы хотим, чтобы нашим сервисом могли пользоваться всегда (вне зависимости от падения машинок) и чтобы при разделении сети (или падении машинки) сохранялись все функции (посмотреть фото / загрузить фото) мы приходим к системе с равноправными узлами (каждый хранит свою часть информации и каждый может отвечать на запросы). Это автоматически даёт нам A и P. При разделении сети / проблемами с машинкой, однако, пользователи не смогут увидеть части фоточек - каких именно определяется Partition Key (логично сделать с привязкой к региону / времени, но у меня сделано чуть проще - PK являяется логин) Насчёт Consistency в Cassandra. Она обладает широкими возможностями по настройке того, нужна ли нам Strong Consistency (тогда это CP система) или же Eventual Consistency. Эти настройки раздельны для чтения и записи. Настраивается также и replication фактор (и стратегия репликации). Опираясь на эту презентацию http://www.slideshare.net/DataStax/understanding-data-consistency-in-apache-cassandra - (слайд 8) - для обеспечения Durability и EC я бы выбрал стратегию с чтением / записью в кворум (т.е. как минимум replication_factor + 1 / 2 реплик с данной колонкой должны быть доступны). Мы жертвуем теоретический availability - но зато более менее гарантируем адекватность информации в репликах. Всё рассмотренное - в пределах одного датацентра, при дальнейшем масштабировании надо думать Итого - почти полностью A, полностью P и довольно неплохой C - кажется, неплохой трейдофф

---

Database structure

В этой части - просто команды для создания табличек в Cassandra + небольшое описание

cqlsh> DESC TABLE img2web.
images subscriptions users

Итого у нас 3 таблички (в KEYSPACE img2web)

CREATE TABLE images ( login text, ts timeuuid, img text, PRIMARY KEY ((login), ts) ) WITH CLUSTERING ORDER BY (ts DESC)

Таблица с картинками каждого пользователя, хранит информацию о логине, времени отправки, самой картинке в base64. PartitionKey - login (т.е. в случае проблем с дц устаревшими - т.е. из несинхронизированной реплики -могут оказаться записи только некоторых пользователей - это хотя бы последовательно). Clustering Order по времени отправки по убыванию, т.к. это естественным образом воспроизводит структуру ленты новостей

CREATE TABLE subscriptions ( login_from text, login_to text, PRIMARY KEY ((login_from), login_to) ) CREATE INDEX followers ON subscriptions (login_to);

Собственно кто на кого подписан. По этой же табличке построен обратный индекс (чтобы быстро понимать, кто подписан на тебя)

CREATE TABLE users ( login text, PRIMARY KEY ((login)) ) Собственно табличка со всеми пользователями нашего сервиса

Такая структура даёт нам одно суперское преимущество - изображение постится с помощью одного обращения к базе с одной командой на запись. Если умножить это на скорость записи в кассандре - получается вообще отлично. С чтением своей ленты всё чуть сложней - придётся сначала вычитать в память список тех на кого ты подписан, а затем запросом к images WHERE login in (те, на кого ты подписан) выбрать нужное. Это хоть и будет делаться параллельно - всё равно не супер.