Данные в любом приложении являются ключевым фактором простоты их понимания. Со временем вырабатывается определенный подход к их выборке, обработке и обновлению. Если обрабатывая данные вы все еще задумываетесь над тем в какой форме хранить ваши данные, как из списка выбрать то что нужно — возможно данный подход упростит вашу жизнь. Основные требования к хранению данных могли бы звучать как то так:

Структура максимально близкая к реляционной. Подобная форма хранения данных завоевала популярность у разработчиков и мы не будем от нее отказываться.

Данные должны обеспечивать простоту доступа к основному элементу по идентификатору. Взаимосвязи со смежными элементами строятся на основе использования вторичного ключа в качестве указателя на основной элемент. Быстрый доступ будет плюсом.

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

Дополнительным бонусом будет использование «налету» что позволит обращаться к объектам через несколько уровней.

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

Вышел новый релиз персональной облачной платформы ownCloud 9.0.

Я уже писал про ownCloud раньше. Я очень люблю этот комбайн из хранилища данных с синхронизацией, версионированием, галереей, календарем, хранением контактов и прочими плюшками. Серверная часть написана на PHP, поддерживаются протоколы WebDAV, CardDAV, CalDAV. Клиентский софт есть под Linux, OS-X, Windows, мобильных платформы и через web интерфейс. В теории может работать с петабайтными объемами данных.

Сервис может работать в федеративном режиме — есть возможность объединять и линковать независимые ownCloud-инстансы, делиться каталогами и другими данными. В качестве файловой системы можно использовать GPFS, GlusterFS и другие распределенные варианты. Хорошо допилена интеграция в инфраструктуру Amazon.

Changelog:

1. Возможность добавлять комментарии и теги к файлам
2. Новая система уведомлений
3. (Федеративный режим) Автодополнение имен пользователей
4. (Федеративный режим) Списки доверенных серверов
5. Код для дополненией и основных файлов наконец подписан
6. Добавили новую систему обновления
7. Улучшения производительности при совместном доступе к каталогам
8. Новое API для External Storage
9. Различные улучшения системы безопасности

Читать дальше →

Вы можете сказать, что “иногда бывает нужно...” Но на самом деле, вы хотите всегда видеть, что у вас в логах, через графический интерфейс. Это позволяет:

• Облегчить жизнь разработчикам и сисадминам, время которых просто жалко и дорого тратить на написание grep-конвейеров и парсеров под каждый отдельный случай.
  
• Предоставить доступ к информации, содержащейся в логах, умеренно-продвинутым пользователям — менеджерам и техподдержке.
  
• И видеть динамику и тенденции появления залогированых событий (например, ошибок).

Так что сегодня вновь поговорим о стэке ELK (Elasticsearch+Logstash+Kibana).
Но на этот раз — в условиях json-логов!

Такой use case обещает наполнить вашу жизнь совершенно новыми красками и заставит испытать полную гамму чувств.


Читать дальше →

Однажды я увидел этот баннер и решил, что бесплатный терабайт мне совсем не помешает, тем более, что мой архив фотографий и документов как раз лежал на терабайтном винчестере. Признаюсь, я очень опасался ставить на компьютер программу с логотипом mail.ru, но стремление к халяве пересилило. Я зарегистрировался, получил место, установил клиент, настроил его и забыл.

А несколько месяцев назад произошло неизбежное — мой жёсткий диск с архивом приказал долго жить. К счастью, к тому времени все файлы были скопированы в облако и ничего не потерялось.

В конце статьи есть UPD, UPD2 и UPD3.
Но радоваться было рано