Привет ! креативненько :) https://www.facebook.com/photo.php?fbid=1594820807436224 -- Best regards, Alexander V Soroka http://www.svr.ua/ AS106-RIPE mailto:alex@euro.net.ua

Добрый день. Сeph используем для внутренних нужд. В режиме fs через ceph-fuse. Все плохо. Медленно, иногда случаются затыки на запись. Хотим что-то другое. Где-то в интернетах рекомендуют, как блочное устройство. Говорят постабильней, и быстрее. Но, тогда не получается несколько точек на запись А для картинок используем Riak CS. Как альтернативу совместимую с amazon s3, на которой были раньше. В общем-то неплохо работает, и масштабируется до бесконечности. 22 декабря 2015 г., 15:09 пользователь Vasiliy P. Melnik написал:

Здравствуйте Сергей.

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

14 июля 2015 г., 17:10 пользователь Serge Negodyuck < petr@petrovich.kiev.ua> написал:

14 июля 2015 г., 16:34 пользователь Vasiliy P. Melnik

...

написал:

...

Насколько это нормально-ненормально? Смотря что считать нормой :)

Многие ORM-ки для того, чтобы считать одну колонку в таблице, считывают всю строки базы даных. Если понадобится другая колонка ниже по коду, повторный запрос делать не нужно. Казалось бы, overhead. Но, например, postgres, все-равно считает с диска всю строку. И поэтому нет смысла читать одну колонку.

На prom.ua, например, на 300Mbit/s исхода (html пожатый gzip), 1.5Gbit/s трафика на базу.

Tue, Jul 14, 2015 at 20:31:48, hunter wrote about "Re: [uanog] sql traffic":

...

Есть портал, типа olx-а, достаточно посещаемый. Трафик исходящий примерно 50 мегабит, на этих 50 мегабит исходящего трафика к клиенту, при чем в этом трафике много графики, сервер баз данных имеет среднюю загрузку интефейса 150 мегабит.

Ситуация типичная для сайтов, где морда сайт фактически является интерфейсом к базе данных и нет кэширования или оно не возможно. Худшее, что я видел, это на 500 мегабит от базы данных отдавалось примерно пять наружу. :)

То есть внутренний трафик в 100 раз превосходил внешний? У facebook этот коэффициент около 900, по тому, что я слышал. И ничего, живут и развиваются, [редиски]. ;-\

Если в остальном производительность устраивает, то я бы не дергался.

Вопрос тут действительно в эффективности - наши сайтостроители иногда ухитряются совершенно безумные решения делать. Есть хрестоматийный пример с форумом, который просматривается этак на 200-й странице. Первый шаг: типичный представитель Duppa Govnosite Ltd. пишет SELECT {всё, что можно, с 10 каскадами JOIN} FROM topics ORDER BY topics.ts_posted DESC (очень гордясь последним словом и тем, что весь этот каскад JOIN'ов вообще смог скомпилироваться парсером выбранного SQL), и отбрасывает из начала нужное количество данных. В зависимости от настроек БД, ответы или отдаются построчно сервером (тогда это проживёт чуть дольше), или отдаются целиком клиенту и разгребаются на нём (типично для MySQL). Отлично работает на почти пустой тестовой базе, перестаёт удовлетворять после первых пары сотен тем - процессы веб-сервера просто падают (хорошо, если не роняя весь сайт). Второй шаг: получив по шее за предыдущее решение, аффтырь дочитывает до наличия потрясающих слов LIMIT и OFFSET в доступном варианте SELECT и дописывает их в предыдущее. Клиентская сторона прекращает падать. Сервер живёт некоторое время, пока объём ответа не начинает превосходить ресурсы (LIMIT+OFFSET отрабатываются уже после фильтрации по WHERE и после всех JOIN). Третий шаг: аффтырь дочитывает stackoverflow с аналогами до гениального, как ему кажется, решения: SELECT {опять всё, что можно} FROM topics WHERE msgid in (SELECT msgid FROM topics WHERE фильтры LIMIT k OFFSET n). 99% на этом и останавливаются, перебрасывая SQL-писателя на придумку новых модных тем на CSS. Пользователи, в зависимости от ситуации, или тихо ругаются, или зеленеют с разбиванием мониторов и клавиатур, от того, что вынуждены по 3-му разу читать давно прочитанные темы от того, что понятие "N первых" сменилось оттого, что спамер вкатил 100 новых тем (а потом снова сменилось назад, когда модератор их удалил, и они пропускают какие-то темы). Но Всем Пофиг (tm), потому что реклама продолжает показываться. До четвёртого шага - вместо "OFFSET n" делать "WHERE id < last_seen_id" и передавать этот самый last_seen_id в запросе HTTP вместо номера страницы - доходят считанные единицы - в чистом виде это я видел только у facebook (из чего видно, кто в нашем земном вебе работает с реальными нагрузками - а остальные только шумят). См. "aftercursorr=" в query в переходах на m.facebook.com. Кроме них, я вижу озаботившихся тем, чтобы не было таких дурных сдвигов, только разрабов ithappens.me с сиблингами: но те сделали, наоборот, фиксированную нумерацию от начала времён (а переход со входной страницы на нумерованную зафиксировали за счёт переменного размера входной - действительно умеют думать, молодцы). Садомазохистское удовольствие от использования подобных сайтов обычно усугубляется кнопками для хождения между страницами, не проверявшимися на эргономику прохода далее входной страницы. Чаще всего "вперёд" и "назад", причём "вперёд" это в прошлое (очевидно, светлое?), а "назад" это в будущее (надо полагать, мрачное и безысходное - не то шумерские плачи по Золотому Веку, не то индийская Калиюга в разгаре, в общем, неуютно - надо идти вперёд в прошлое, где поднималось то, что нужно, а не артериальное давление). То же самое "следующая страница" и "предыдущая". Но в некоторых местах (LOR), "вперёд" это в будущее, а "назад" это в прошлое (люди хотя бы немного оптимизма показали, уже хорошо). Самый хит дебилизма - "сюда"/"туда" на Хабре с аналогами (Ржевский негодует). Написать на кнопках слова, явно означающие направление времени (например, "раньше"/"позже"), это уже выходит за пределы способностей очень серого вещества... -netch-