Манифест асинхронного хранилища данных

Моя работа с хранилищами данных NoSQL за последние пару лет дала мне некоторое представление о направлении, в котором неизбежно пойдут приложения, поскольку NoSQL становится доминирующим методом хранения и извлечения данных — по крайней мере, для веб-приложений и облачных приложений (корпоративные приложения будут в конечном итоге достигнуты , но это займет намного больше времени). За эти годы я научился доверять своим инстинктам, и мои инстинкты кричат ​​мне, что этот подход имеет ценность и должен быть кем-то исследован, даже если у меня лично нет времени на написание этой системы.

Асинхронный доступ

Я думаю, что весь подход основан на неблокирующем асинхронном доступе к данным. Вообще говоря, если мы хотим использовать асинхронный обмен сообщениями в наших приложениях, мы должны были бы заручиться помощью брокера сообщений, единственной целью которого является асинхронная маршрутизация сообщений. Мой любимый, как вы, без сомнения, знаете, это RabbitMQ . Но пытаясь расширить некоторые ключевые функциональные возможности RabbitMQ и понять, насколько это сложно на практике, я предполагаю, что можно добиться большего прогресса быстрее, используя гораздо более легкую асинхронную библиотеку, не имеющую соответствия конкретной протокол, как делает RabbitMQ для AMQP.

На мой взгляд, Node.js изменил форму разработки веб-приложений в лучшую сторону. Хотя его истинные асинхронные приложения сложнее создать (поэтому они пока еще не так популярны среди рядовых пользователей), они явно более масштабируемы и работают лучше в облачной среде, где пользователю может потребоваться множество относительно небольших экземпляров виртуальных машин. которые могут координировать друг с другом. Обмен сообщениями является логичным выбором для достижения этой цели.

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

Но я не доволен хорошим. Когда-либо.

Данные король

Если мы сократим наше приложение до его самой чистой формы, единственное, что нас волнует, это данные. Я мог бы выбрать что-то вроде моего любимого хранилища данных NoSQL, Riak, потому что оно может масштабировать мои данные, и я могу выполнять распределенное Map / Reduce для своих данных. Но данные являются основной причиной заявки в первую очередь. Все, что я делаю внутри приложения, делается в контексте данных. Если я использую брокер сообщений, сообщения являются данными. Если я размещу веб-форму, я принимаю данные. Если я создаю отчет, я сообщаю о данных.

Ничто не имеет значения, кроме данных.

Но брокеру сообщений нет дела до данных. Это просто проводник. И хранилище сообщений не заботится о проводнике. Но это действительно не должно быть так.

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

Представьте, что мне нужно конвертировать и масштабировать загруженное изображение в миниатюру. Для этого я пишу простую программу, которая использует ImageMagick для масштабирования, обрезки и преобразования изображения в JPEG. Я также создаю веб-форму, которая позволяет пользователю загружать свое изображение. В этом мире асинхронного хранилища данных логика моего преобразователя изображений должна иметь возможность прослушивать события INSERT или UPDATE в хранилище данных и преобразовывать входящие данные, автоматически сохраняя миниатюру загруженного изображения.

Псевдокод конвертера изображений:

def db = asyncdb.connect("tcp://localhost:5555") 
def img = request.get_upload_data("image") 
def metadata = [ content_type: "image/jpg" ] 
db.push("imagebucket", img.name, img.data, metadata, { event, data -> 
  if(event.type == SUCCESS) { 
    db.push("profilebucket", "$user.profile", [ avatar: data.key + ".thumbnail" ]) 
  } 
})

def db = asyncdb.connect("tcp://localhost:5555", [ name: "image.converter", 
                                            description: "Image thumbnailing listener" ])

def db = asyncdb.connect("tcp://localhost:5555", [ name: "image.converter", 
description: "Image thumbnailing listener" ])