Skip to content

Instantly share code, notes, and snippets.

@didlidu
Last active October 20, 2016 09:19
Show Gist options
  • Save didlidu/345fe4f8e0ed5fd5e38e3cdab359d07a to your computer and use it in GitHub Desktop.
Save didlidu/345fe4f8e0ed5fd5e38e3cdab359d07a to your computer and use it in GitHub Desktop.
DB spec

Основные требования

Задача

Создание распределенного хранилища пользовательских изображений.

  • Пользователь в своем приложении сохраняет изображение под уникальным именем (ключом). При коллизии имен выводится ошибка.
  • Изображение сохраняется в распределенную бд.
  • Сохнаненные изображения могут быть получены из бд по имени.
  • Конечный сервер фактического хранения данных выбирается случайным образом, либо по какой-нибудь простой метрике (например, по заполненности данными)
  • Пользовательское приложение общается с центральным сервером (СУБД), на котором данные не хранятся. Сервер предоставляет API для доступа к данным.
  • Сервер взаимодействует со всеми бд, реплицируя на них запросы получения данных.
  • Конечный сервер фактического хранения данных предоставляет интерфейс записи и считывания данных.
  • Конечный сервер фактического хранения данных хранит данные в виде ключ - значение.

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

Требования к реализации

  • Протокол взаимодействия - высокоуровневый, что-то типа TCP или даже HTTP
  • Тип сообщений - json (?)
  • Представление изображений для хранения и передачи - текстовое (?), base64 (?)
  • Ключ = хэш_сумма(ключ), md5 (?)
  • Способ хранения данных - выбирается человеком, реализующим эту подсистему, самостоятельно. Существующие способы:
    1. Большооой файл, кэширование его в память полностью при малых размерах, при больших однопроходной линейный поиск по файлу, оптимизации по желанию. Структура, например, такая: <флаг><ключ><размер><значение><флаг><ключ><размер><значение><флаг><ключ><размер><значение>... Добавление данных в конец файла, флаг сигнализирует об удалении следующей пары.
    2. Хранение документов в файловой системе, один документ - один файл. В данном случае путь вычисляется следующим образом. Допустим, ключ документа f8e1c82556d24f478a1d0867892079f0 Тогда путь будет следующий: f8/e1/c8/25/56/d2/4f/47/8a/1d/08/67/89/20/79/f0 , где f0 - имя самого файла.

Прикладное приложение

Сервер (СУБД)

Хранилище

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment