Под катом тезисы, хочется знать, что из этого вызовет интерес, а что сократить
Доклад рассчитан на начинающих архитекторов и ведущих программистов. В первой части доклада будет обзор про то, как устроена современная Служба знакомств изнутри на примере LovePlanet.ru. Будет предложена концепция модульной архитектуры, когда за определенную задачу отвечает отдельный модуль, который реализован как самостоятельная служба или демон. Что дает нам такая архитектура и в чем преимущество перед выполнением обычных WEB страниц.
Одним из модулем нашей архитектуры является Сервис «Хранения предпочтений», который реализован в виде key/value хранилища с дополнительной логикой. Почему нам пришлось создать собственное NoSQL хранилище, почему не подошли memcached, membase, redis, tarantool или MongoDВ? Об этом и многом другом можно узнать во второй части этого выступления. Какие велосипеды нам пришлось изобретать и что мы взяли уже готовое, а так же:
— Протокол обмена, почему выбрали именно memcached
— Расширение протокола и использование родного memcached клиента. Что работает, а что осталось теорией.
— Как устроено хранилище изнутри (на базе key/value Hash & Tree), придется немного усвоить скучной теории, чтоб понять как и зачем тюнить хранилище.
— Как мы организовали мониторинг.
— С какими столкнулись проблемами при переходе с memcached на собственное хранилище.
Доклад рассчитан на начинающих архитекторов и ведущих программистов. В первой части доклада будет обзор про то, как устроена современная Служба знакомств изнутри на примере LovePlanet.ru. Будет предложена концепция модульной архитектуры, когда за определенную задачу отвечает отдельный модуль, который реализован как самостоятельная служба или демон. Что дает нам такая архитектура и в чем преимущество перед выполнением обычных WEB страниц.
Одним из модулем нашей архитектуры является Сервис «Хранения предпочтений», который реализован в виде key/value хранилища с дополнительной логикой. Почему нам пришлось создать собственное NoSQL хранилище, почему не подошли memcached, membase, redis, tarantool или MongoDВ? Об этом и многом другом можно узнать во второй части этого выступления. Какие велосипеды нам пришлось изобретать и что мы взяли уже готовое, а так же:
— Протокол обмена, почему выбрали именно memcached
— Расширение протокола и использование родного memcached клиента. Что работает, а что осталось теорией.
— Как устроено хранилище изнутри (на базе key/value Hash & Tree), придется немного усвоить скучной теории, чтоб понять как и зачем тюнить хранилище.
— Как мы организовали мониторинг.
— С какими столкнулись проблемами при переходе с memcached на собственное хранилище.
