RSS Записей | RSS Комментариев
Ядоблог - Stay upwind

Архив ‘Алгоритмы’ Категории

sphinx, xmlpipe2, PHP и MongoDB или загибаем трубу из MongoDB в сфинкс, используя PHP

мая 22, 2012 | Комментариев нет

ТЗ: организовать релевантный поиск.

ТУ: данные хранятся в MongoDB, бэкенд на PHP.
Читать полностью »

Пять копеек о SQL

июля 17, 2011 | 3 Комментариев

Предложите решение в комментах.

Задача: хранить Игроков

Варианты решения 3 штуки(смотри картинки снизу. Слева объектная структура данных, справа способ хранения):

1. В одной таблице

2. Разделять по типам игроков и хранить в «типизированных» таблицах

3. Смешанный стиль — одинаковую информацию в главной таблице и типизированную информацию в типизированных таблицах

MySQL vs MongoDB. Более сложный insert (для mongodb) часть 3.

марта 25, 2011 | Комментариев нет

В продолжение решения задачи: Реляционка или не реляционка

Пройдя первый этап: MySQL vs MongoDB. Сравнение скорости insert Создания пользователей.

Пройдя второй этап:MySQL vs MongoDB. Более сложный insert (для mongodb) Создания друзей.

Пройдя третий этап: MySQL vs MongoDB. Более сложный insert (для mongodb) часть 2. Создания фотографий у каждого пользователя

Теперь пометим у каждого френда (100 френдов у каждого из 1000 пользователей) по 50 фотографий из 100 просмотренными. Получается 1000*100*50=5000000 (пять миллионов записей):

Для MySQL это вставка в таблицу who_view_photo записи с id_photo и id_user просмотревшем его.

Для MongoDB это изменение существующих объектов в коллекции пользователей. Причём мы меняем 3-й уровень объекта в глубину:

Посмотрим насколько шустро отработает наш MongoDB. Ему уже приходится в каждом объекте содержать информацию о 100 друзьях и 100 фотографиях (1000 записей).

По оси Х-время, по оси Y-количество случаев с данным временем. На примере вставки первых 50000 элементов (просмотров фотографий):

Вывод: Объекты MongoDB разжирнев, обрабатываются дольше, чем банальная вставка значения в таблицу MySQL. Но даже содержа 1000 значений в объекте, выполняя фактически операцию update к объекту (меняя его содержимое) мы получаем все-лишь двукратное замедление, что радует.

MySQL vs MongoDB. Более сложный insert (для mongodb) часть 2.

марта 25, 2011 | Комментариев нет

В продолжение решения задачи: Реляционка или не реляционка

Пройдя первый этап: MySQL vs MongoDB. Сравнение скорости insert Создания пользователей.

Пройдя второй этап:MySQL vs MongoDB. Более сложный insert (для mongodb) Создания друзей.

Создадим фотографии пользователей. Каждому пользователю по 100 фотографий.

Для MySQL это обычное создание записи в таблице:

Для NoSQL это добавление в коллекцию пользователей из MySQL vs MongoDB. Более сложный insert (для mongodb) ещё одного поля photos, являющегося множеством элементов.

И сравниваем производительность выполнения вставки 100 фотографий каждому из 1000 пользователей (100000 элементов).

По оси Х-время в секундах, по оси Y-количество случаев с данным временем выполнения(основной кусок увеличен):

Вывод: нужно понимать, что для MySQL — создание фотографии лишь вставка новой записи в таблицу фотографий, а для MongoDB — изменение существующего объекта, в котором уже содержится 100 друзей, созданных в предыдущем этапе, и ещё добавляется 100 элементов фотографий. Но при всём этом MongoDB половину операций (~50000) отработало за 0.0001 секунды, а MySQL редко ранее 0.0005 секунды. И MongoDB пришлось проделать гораздо большую работу (обновить существующие объекты).

MySQL vs MongoDB. Более сложный insert (для mongodb)

марта 25, 2011 | Комментариев нет

В продолжение решения задачи: Реляционка или не реляционка

Пройдя первый этап: MySQL vs MongoDB. Сравнение скорости insert

Создадим для 1000 пользователей системы по 100 друзей каждому (1000*100=100000 записей).
В MySQL мы имеем структуру:

Таким образом для MySQL это будет вставка записи в таблицу friends.
В MongoDB мы имеем структуру сложнее. т.к. вся информация представлена в виде большого дерева.
Мы имеем коллекцию пользователей. В которой все наши 1000 пользователей как документы.
Каждый документ имеет структуру:

  1. поле id_user
  2. массив ifriends состоящий из элементов id_friend (ссылка на другой элемент этой же коллекции users)

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

Вывод: тут нужно понимать, что в mysql — обычная вставка данных в таблицу, а в MongoDB — обновление существующего объекта — создание в его поле ifriend ещё одного элемента, хоть и с одним значением id_friend, но всё-же это update. Ну и мы видим, что выполнив 100000 таких операций мы имеет сравнимо одинаковые затраты по времени.

MySQL vs MongoDB. Сравнение скорости insert

марта 25, 2011 | 2 Комментариев

Для решения задачи Реляционка или не реляционка

Вставим 1000 записей в таблицу. Для чистоты эксперимента в таблицах уже по 10000 записей.

UPD: переделал сбор статистики и запустил на нормальном сервере. Результаты разительно другие (по Х-время в секундах, по Y-количество случаев):

Вывод: видим явно более быструю работу insert в mongodb. Нужно понимать что операции происходят в памяти, никакого обращения к диску не происходит. В обоих случаях. =)

Реляционка или не реляционка

марта 25, 2011 | Комментариев нет

Попробуем решить интересную задачу двумя способами (реляционным и не реляционным).
Допустим есть социальная сеть.
В ней есть пользователи, которые помечают других пользователей френдами.
Пользователи выкладывают какие-либо фотографии.

Задача: Для текущего пользователя вывести список всех фотографий френдов, которые этот пользователь ещё не просмотрел. О_о

Бум использовать:
php фреймворк CodeIgniter
mysql для реляционки
MongoDB для NoSql

Начальные данные:
1. создадим 1000 пользователей
2. для каждого пользователя зададим 100 друзей
3. для каждого пользователя зададим 100 фотографий (получится всего 100,000 фотографий О_о)
4. каждым пользователем посетим случайные 50 фото каждого своего друга (50*100*1000=5,000,000 записей)
5. каждым пользователем посетим случайные 1000 фото (1,000*1,000=1,000,000 ненужных записей дополнительно)

Ну и область наших интересов — быстродействие
Пока в процессе проектирования — пишите что-нить =)

О парсерах. К размышлению.

февраля 3, 2011 | 2 Комментариев

наткнулся на видео, к презентации, о которой писал http://lenta.iadlab.ru/2010/10/12/o-parsinge-ideya-prosto-genialnaya/

© 2010 Ядоблог. Все права защишены.
Powered by Лаборатория Яда. Написать администратору