Он достаточно надёжен для поставленной задачи.

недостаточно производителен.

эээээ

но это ИМХО

Народ, вы о чём вообще? Вы на какую комманду и при каких сроках разработке думаете, когда всё это пишите?

И куда, и как часто это потом сливать?

говорю же - поставить Kafka. Сливать по мере поступлений и разгребания сообщений в БД. у меня так просто обычно сразу в агрегирование шло (Hadoop)

а вообще согласен с @etkee рсубд там не очень нада

это проект ставит требования по команде и ресурсам, а не наоборот

если вы хотите реализовать круглогеографическую штуку, то на мускуле туда нормально не въехать

КОТ ну минимальная реализация с нуля это где то полгода в шестером

по опыту.

на три инсерта!

можно конечно городить, но куда вы побежите когда траф пойдет и всё ляжет к чертям ?

КОТ ну минимальная реализация с нуля это где то полгода в шестером

Круто, с этого стоило начинать. Реалии: 1 в 3 месяца - НАДО.

шесть инсертов вам выйдут дороже!

(такие примеры перед глазами есть)

я немного более оптимистичен, но да, судя по косвенным признакам предположу, что проект там на такие сроки

когда сеть рекламная тупо не смогла обеспечивать запросы менеджеров и была погребена под трафом

можно конечно городить, но куда вы побежите когда траф пойдет и всё ляжет к чертям ?

Ну сейчас у меня идёт 1М трафа и на него тратится 5% запаса ресурсов

1М в день

Такая, плавная раскачка

Но запаса там жопой жуй.

ты уверен, что у тебя нет экспоненциально растущих бутылочных горлышек?

это 11 запросов в секунду..

ты уверен, что у тебя нет экспоненциально растущих бутылочных горлышек?

Есть, суммирование

ну дык

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

это 11 запросов в секунду..

На деле наливают пока не равномерно, потому когда идёт траф то 300-500 переходов в секунду

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

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

Моя цель в этой системе - выдерживать траф в размере 100-150М дейли

тогда норм. единственное, что клиентов сильно потеряете, когда первый раз не сможете прожевать. в системе с просто БД у вас нет шансов, все падает сразу

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

тогда норм. единственное, что клиентов сильно потеряете, когда первый раз не сможете прожевать. в системе с просто БД у вас нет шансов, все падает сразу

А это уже моя задача с одной стороны следить за запасом ресурсов, с другой тормозит продажников, если надо

и как это соотносится с СУБД? во-первых, она без шарденинга не масштабируется горзонтально. по-хорошему оно должно быть строго на физических серверах, виртуализация снижает производительность практически вдвое при тех же ресурсах. ну опять-таки, вам надо набить шишки самостоятельно, видимо.

Виртуальност чего?

если ты поднимешь Х в виртуальной машине, то его скорость записи на диск будет ниже, чем на железе (да и обычных операций тоже)

именно для СУБД виртуализация критична - скорость сильно падает.

Ты с Амазоном хорошо знаком?

нет. я разрабатывал другое облако.

Железку, та которая ес2, само вычеслительное... блин, короче там шкафы с матплатами+цпу+рам и отдельные шкафы с ССД дисками

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

А харды в свою очередь выделяют пространство, на один ГБ 3 ИОПС, при этом разрешают пики, у меня при выделеных 300 ИОПС пики доходят до 2000 ИОПС

Учитывая, что они нарезают тебе пространство на разных дисках, то загрузка в среднем выравненая и с запасом

у меня такое ощущение, что если взять те деньги, которые вы тратите на амазон, и пустить на вышеописанный продукт, то вы и команду найдете, и в сроки его сделать успеете

Мы тратим не больше 1К$ сейчас на амазон

но если у вас есть рабочий бизнес, который производит ресурсы для развития, то жесткость по срокам я не очень понимаю

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

Ну на данный момент они не выделеные, потому я этого и не говорил, если будут траблы, то апгрейднемся

р3 кстати насколько я понял тоже шаред

Там дедикэйтед отдельная галочка

да, сейчас глянул. но у нас на одном проекте работает. не сильно нагруженном

761$ с начала месяца, нормально в установленый бюджет укладываюсь.

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

В среднем 10% прибыли на ИТ структуру можно брать

Ну потом может и впилим, когда будет достаточно мозгов, которые в этом шарят

Сейчас же мне надо уже существующий движок чутка перепилить, и сделать более быстрым для всех локаций.

Потому и такой выбор подхода к решению задачи.

frontend responders -> post message and ok message listeners -> listen and push to DB все остальное не меняется

Посмотри кассандру кроме шуток, как она работает, как себя ведет в тех или иных ситуациях. Через месяц перестанешь за мускулем гоняться.

frontend responders -> post message and ok message listeners -> listen and push to DB все остальное не меняется

О! Я тут кое чё вспомнил, чё забыл ))) С того одного INSERT´а, который обязательный, надо возвращать авто инкреминент )

и с инкрементов лучше на uuid переходи

И да про очереди

в данном случае просто пихай его в соседнюю очередь и пусть другой это разбирает

Извиняюсь, что с таким запозданием понимаю суть (в голове тоже видимо всё на очередях)

Понимаешь в чём дело, вот очереди, на какой срок они могут отложиться?

сам конифгурируешь. у rabbitmq надо просто заголовок добавить при отправке сообщения / при создании очереди

Я к тому, что через буквально долю секунды, может вернуться отстук, с этим самым авто инкрименентом, и надо записать это

ERROR: S client not available

То есть к тому, что существует, дописать обновление

генерируй идентификатор на фронтенде

А если он будет в очереди парится? Куда я буду это записывать?

И что мне даст эта генерация?

принял сообщение на внешнем сервере - придумал ему идентификатор - отправил в очередь - отправил идентификатор клиенту

клиент придумал добавить что-то - у него есть идентификатор

тебе мониторинг просто нужен за количеством сообщений в очереди

Да, у него есть идентификатор

И чего мне с ним делать, если его в базе ещё не окажется?

в худшем варианте отправить сообщение обратно в очередь с уменьшенным ttl

Так

Давай по порядку, распишу. У меня есть поставщики трафика и рекламодатели. Рекламодатель пишет, сколько он готов потратить в день, я ему отливаю, излишек уходит в сторону. Ты предлагаешь очереди, я переливаю, оно конвертит, мне рекломадатель говорит "Я столько не заказывал!", далее, на очередях если потеряется отстук конверсий, и я их не передам дальше поставщику трафика, то мне либо начнуть отружать более дешёвый и мнее качественный трафик, либо тупо перекроют поставку.

Вот по этому, все эти очереди они не катят.

Посмотри записи докладов последнего highloada

я очереди как раз не предлагал )

принял сообщение на внешнем сервере - придумал ему идентификатор - отправил в очередь - отправил идентификатор клиенту

Вот тут я решил, что ты тоже за идею с очередями

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

тут не очень возможно действовать старыми методами

но пока ты льешь рекламу и можешь прогнозировать поток пользователей в следующие пять минут, ты можешь обрубить показ в нужное время плюс-минус небольшая погрешность

и это нормально

все большие штуки так работают

Надо видео дождаться, но насколько я запомнил, они пришли к битовой маске, но всё равно СУБД

Вбросил к тому, что даже такие потоки используют СУБД, но блин, сейчас не смог это в призентации найти, так что пока утверждение со звёздочкой.

да можно это все и на мускуле сделать, но минусы эксплуатации перевешивают плюсы

очереди вполне вариант. просто я не вижу необходимости из-за отсутствия непрогнозируемой нагрузки и возрастающей сложности

можно взять любое нормальное k-v хранилище и избежать большинства проблем, получив вдобавок возможность в любой момент приглушить любой сервер и сделать с ним, что угодно

Я не против межгалоктических космолётов, но с серпом и мотыгой их не построить.

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

ну, если сеты там умеют схлопываться

Вот потому, я совершенно чётко описал условия задачи, и попросил ответить на описаный кейс, а не предлогать другие пути решения задачи

Вот реально, парни, написал в 15:19 сейчас 21:02, проебал почти 6 часов времени, не сделав несколько важных тасков, потому, что лазил читать, про тарантулы, про касандры, апача кафки, отложеные очереди и прочую туфтохрень. Я даже не знаю, какими ещё нормальными словами, описать суть того, что я хочу донести. Просто очень устаёшь, когда в 80% чатов/форумах/ещё где-то, на простейшии вопросы люди, которые могут ответить нормально, отвечают кашей. НАХУЯ?