Резюме.
P.S.
Предыдущий пост был тренировочным :)
30 Май 2009 г.
19 Сентябрь 2008 г.
myPicturetown +Google Maps
Новая версия нашей поделки www.mypicturetown.com теперь умеет Google maps. И, кстати, совершенно случайно, новая камера от Nikon COOLPIX P6000 имеет GPS приемник на борту. Теперь, можно не только хостить свои фотографии и альбомы, но и смотреть по карте где была сделана каждая фотография и даже отследить свой туристический маршрут :)
Еще одна полезная функциональность теперь поддерживается. Если фотография НЕ имела никакой геоинформации, тогда вам достаточно ее загрузить на сайт mypicturetown.com указать на карте где был сделан этот снимок и при следующем download/sharing эту фотографию сервер снабдит соответствующими EXIF тэгами с GPS информацией. Далее - можно с ней хоть на Flickr хоть на Picasaweb.
Удачи!
Еще одна полезная функциональность теперь поддерживается. Если фотография НЕ имела никакой геоинформации, тогда вам достаточно ее загрузить на сайт mypicturetown.com указать на карте где был сделан этот снимок и при следующем download/sharing эту фотографию сервер снабдит соответствующими EXIF тэгами с GPS информацией. Далее - можно с ней хоть на Flickr хоть на Picasaweb.
Удачи!
16 Август 2008 г.
myPicturetown - "горизонтальное" расширение
Как говорят некоторые коллеги: "тихо и незаметно"...
Дак вот, тихо и незаметно, проект www.mypicturetown.com перешел от простого кластера к полноценной "grid" архитектуре. Если ранее - это был кластер из нескольких серверов поверх условно "центральной" базы данных, то теперь - это большая сеть состоящая из множества, так называемых, "AB" пар (primary-secondary).
Каждая "AB" пара в гриде представляет собой клатер из 2-х хостов (primary - secondary). Причем, кластеризация самопальная. Каждый AB хост имеет как файловое хранилище, так и базу данных (PostgreSQL). Разделение между ними, скорее, master-master нежели master-slave. Дублирование в файловом хранилище реализовано на уровне бизнес логики, а вот дублирование в базу выполняется посредством собственной имплементации JDBC драйвера (на основе HA-JDBC). Конечно же, каждый пользователь (его данные и файлы) "привязан" (размещается) на конкретной AB паре. Ничего удивительного :) Тем более, что это довольно распространенная практика. Конечно встает вопрос о неком "центральном" реестре пользователей. Где хранится информация о том что данный пользователь (с таким то UID) размещается на такой то AB паре.
Однажды, Иван Блинков (кстати, рекомендую посетить его блог) задавал мне вопросы связанные с деталями реализации наших AB кластеров и центрального реестра пользователей (у нас в системе его называют CDC). Теперь, когда мы уже зарелизилист, могу рассказать некоторые "секреты" :)
Итак, про JDBC репликацию я уже рассказал. Конечно же, процедуры восстановления базы данных после сбоя выписаны "руками" поверх все того же HA-JDBC.
Центральный реестр пользователей (CDC) - реализован как кластер из одного или более хостов. В качестве хранилища, использующий Berkeley DB (Java Edition) от ORACLE. Я, как автор CDC, могу "похвастать" еще и тем - что механизм распределенных транзакций сделан собственный. Кроме того, сервис полностью удовлетворяет требованиям "zero administration" и умеет "самовосстанавливаться" и "самореплицироваться".
Для построения кластеров мы активно используем JGroups.
Вот пожалуй и все "секреты", остальное - дело техники :)
Желаю удачи, коллеги!
Дак вот, тихо и незаметно, проект www.mypicturetown.com перешел от простого кластера к полноценной "grid" архитектуре. Если ранее - это был кластер из нескольких серверов поверх условно "центральной" базы данных, то теперь - это большая сеть состоящая из множества, так называемых, "AB" пар (primary-secondary).
Каждая "AB" пара в гриде представляет собой клатер из 2-х хостов (primary - secondary). Причем, кластеризация самопальная. Каждый AB хост имеет как файловое хранилище, так и базу данных (PostgreSQL). Разделение между ними, скорее, master-master нежели master-slave. Дублирование в файловом хранилище реализовано на уровне бизнес логики, а вот дублирование в базу выполняется посредством собственной имплементации JDBC драйвера (на основе HA-JDBC). Конечно же, каждый пользователь (его данные и файлы) "привязан" (размещается) на конкретной AB паре. Ничего удивительного :) Тем более, что это довольно распространенная практика. Конечно встает вопрос о неком "центральном" реестре пользователей. Где хранится информация о том что данный пользователь (с таким то UID) размещается на такой то AB паре.
Однажды, Иван Блинков (кстати, рекомендую посетить его блог) задавал мне вопросы связанные с деталями реализации наших AB кластеров и центрального реестра пользователей (у нас в системе его называют CDC). Теперь, когда мы уже зарелизилист, могу рассказать некоторые "секреты" :)
Итак, про JDBC репликацию я уже рассказал. Конечно же, процедуры восстановления базы данных после сбоя выписаны "руками" поверх все того же HA-JDBC.
Центральный реестр пользователей (CDC) - реализован как кластер из одного или более хостов. В качестве хранилища, использующий Berkeley DB (Java Edition) от ORACLE. Я, как автор CDC, могу "похвастать" еще и тем - что механизм распределенных транзакций сделан собственный. Кроме того, сервис полностью удовлетворяет требованиям "zero administration" и умеет "самовосстанавливаться" и "самореплицироваться".
Для построения кластеров мы активно используем JGroups.
Вот пожалуй и все "секреты", остальное - дело техники :)
Желаю удачи, коллеги!
Подписаться на:
Сообщения (Atom)
