Вопросы проектирования и оптимизации БД для социального приложения

Question

обычный случай.У меня есть простое приложение, которое позволит людям загружать фотографии и следить за другими людьми.В результате у каждого пользователя будет что-то вроде «стены» или «ленты новостей», где он или она увидит последние фотографии, загруженные его друзьями (людьми, за которыми он или она следит).

Большинство функций легко реализовать.Однако, когда дело доходит до этой ленты активности истории, вещи могут легко превратиться в беспорядок из-за просто соображений производительности.

Здесь я столкнулся со следующей дилеммой: я могу легко спроектировать фид активности как нормализованную часть базы данных, что избавит меня от циклов записи, но значительно увеличит сложность при выборе этих результатов для каждого пользователя.(для каждой фотографии, загруженной в течение определенного периода времени, выберите определенное число, чьи загрузчики я отслеживаю / для каждого человека, которого я отслеживаю, выберите его фотографии)

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

Второй подход заключается во введении полностью денормализованной схемы для ленты активности, в которой каждая строка представляет уведомление для одного из моих подписчиков.Это означает, что каждый раз, когда я загружаю фотографию, БД будет помещать n строк в это «поле ввода», n означает количество людей, за которыми я следую, то есть много циклов записи.Если бы у меня была такая таблица, я мог бы легко применить некоторые методы оптимизации, такие как умное индексирование, а также удаление записей старше определенного периода времени (очереди).

Тем не менее, третий подходна ум это даже менее денормализованная схема, в которой приложение на стороне сервера отнимает некоторую часть сложности у БД.Я видел, что некоторые социальные приложения, такие как Friendfeed, сильно зависят от хранения сериализованных объектов, таких как объекты JSON, в БД.

Я определенно все еще осваиваю навык проектирования масштабируемой БД, поэтому я уверен, что есть много вещей, которые я пропустил или еще предстоит изучить.Я был бы очень признателен, если бы кто-нибудь дал мне хотя бы свет в правильном направлении.

Answer 1

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

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

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

Что касается хранения сериализованных объектов, то это хороший вариант, если эти объекты неизменны (вы не измените их после записи) и вам не нужно индексировать их или запрашивать их. Обратите внимание, что если вы денормализуете свои данные, это, вероятно, означает, что у вас есть отдельная таблица для канала активности. В этом случае я вижу небольшой выигрыш в хранении BLOB-объектов. Если вы собираетесь использовать сериализованные объекты, рассмотрите возможность использования какого-либо решения NoSQL, такого как CouchDB - они лучше оптимизированы для обработки данных такого типа, поэтому в принципе вы должны получить более высокую производительность при той же настройке оборудования. Обратите внимание, что я не предлагаю переносить все ваши данные в NoSQL - только для той части, где это лучшее решение.

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

Answer 2

Есть много вариантов, которые вы можете взять

• Добавление дополнительного оборудования , Память, ЦП - Вход в облачный хостинг
• Как звучит 24 ГБ памяти? Большая часть вашей важной информации БД может поместиться только в памяти.
• Выберите хост с расширяемыми SSD.
• Используйте основанную на событиях систему в своем приложении, чтобы написать «историю» всех пользователей. Так будет выглядеть так: id, user_id, event_name, date, event_parameters' - пример будет: 1, 8, CHANGED_PROFILE_PICTURE, 26-03-2011 12:34, <id of picture> и Самое главное, эта таблица будет в памяти. Больше не нужно беспокоиться о производительности записи. После того, как записи пройдут, то есть через 3 дня, они могут быть удалены в другую таблицу (не в памяти) и включены в результаты запроса, если пользователь решит вернуться так далеко. Имея все это в одной таблице, вы избавляетесь от необходимости делать несколько запросов и SELECT для создания этой информации.
• Рекомендуется использовать INNODB для таблицы истории / каналов.

---

Хорошие ресурсы для чтения

• Изучение программного обеспечения Facebook, крупнейшего в мире сайта
• Digg: увеличение производительности на 4000% за счет сортировки в PHP Вместо MySQL
• Кэширование и производительность: уроки из Facebook

Answer 3

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

Answer 4

Я все больше читаю о решениях NoSQL и людях, которые их предлагают, однако никто никогда не упоминал о недостатках такого выбора. Наиболее очевидным для меня является отсутствие транзакций - представьте, если вы теряли несколько записей время от времени (есть случаи, сообщающие, что это происходит часто).

Но меня удивляет то, что никто не упоминает, что MySQL используется в качестве NoSQL - вот ссылка для чтения .

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

Как уже указывалось Elad - создание приложения, которое можно масштабировать с самого начала, является болезненным процессом. Лучше потратить время на то, чтобы сделать его популярным, а затем масштабировать его.

Answer 5

Именно из-за таких проблем в наши дни используются решения NOSql.То, что я делал в своих предыдущих проектах, действительно просто.Я не храню историю user-> wall user->, которая содержит только feed'ы в хранилищах памяти (мой фаворит - redis).поэтому при каждой вставке я делаю 1 операцию вставки в базу данных и (n * read optim) операцию вставки в хранилище памяти.Я разрабатываю хранилище памяти, чтобы оптимизировать чтение.если я хочу отфильтровать историю пользователя (или стену) для видео, я помещаю push-фид в список вроде user :: {userid} :: wall :: videos.

Конечно, вы можете просто построить системуМемориальные магазины тоже есть, но приятно иметь 2 системы, которые делают то, что у них получается лучше всего.

edit: проверить эти приложения, чтобы понять:*http://twissandra.com/