Оплатишь?

Я тебе бенчмарк редиса показал выше :) Бесплатно.

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

Ага.

Спору нет, редиска быстрее постгре

Но он не всегда подойдёт. Точнее не во всех случаях

Спору нет, редиска быстрее постгре

Машинистка, печатаю 900 знаков в минуту. Такая фигня получается!

Так что спор не о чем...

Машинистка, печатаю 900 знаков в минуту. Такая фигня получается!

Зависит от того, что подразумевается под машинисткой)

Так что спор не о чем...

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

Кажется кто-то тут видит будущее и умеет выбирать заведомо верное универсальное решение.

При любых обстоятельствах.

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

Не все условия заведомо известны.

Кажется кто-то тут видит будущее и умеет выбирать заведомо верное универсальное решение.

Да это классика. Логи почти всегда не для БД

Кажется кто-то тут видит будущее и умеет выбирать заведомо верное универсальное решение.

Мне кажется у него на все случаи Постгре подходит ;)

Как минимум потому что там транзакции, которые могут откатиться

Да это классика. Логи почти всегда не для БД

Поясните

Ну пока что это все просто голые утверждения насчет того что оттюненный постгрес чего то там может

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

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

Скорее всего вашей конторе нужен грузовик, а не формула 1

Но у нас были все же кратковременные приступы хайлоада

Один раз было даже все попадало из-за паники пользователей :)

Один раз было даже все попадало из-за паники пользователей :)

Они все дружно начали кликать по ссылочкам?)))

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

Но у нас были все же кратковременные приступы хайлоада

Какой RPS?

там было 400 запросов в секунду к бэкенду

Поясните

СУБД хранит констстентные данные, а неконсистентные отвергает. Логи заведомо не нуждаются в нормализации обычно. Просто складывайте их в любое надежное хранилище и всё. А обрабатывайте когда понадобятся. СУБД тут лишняя

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

Вот же заразы!)))

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

а вы с москвы ребята?

СУБД хранит констстентные данные, а неконсистентные отвергает. Логи заведомо не нуждаются в нормализации обычно. Просто складывайте их в любое надежное хранилище и всё. А обрабатывайте когда понадобятся. СУБД тут лишняя

А с чего Вы взяли, что эти логи не нуждаются в нормализации?

а вы с москвы ребята?

Нет

СУБД хранит констстентные данные, а неконсистентные отвергает. Логи заведомо не нуждаются в нормализации обычно. Просто складывайте их в любое надежное хранилище и всё. А обрабатывайте когда понадобятся. СУБД тут лишняя

И постгрес тут нинужен. А если сразу лог обрабатывать, то нужен, и редиска его не заменит

а откуда?

А с чего Вы взяли, что эти логи не нуждаются в нормализации?

Мгновенной, сразу по поступлению?

Мгновенной, сразу по поступлению?

Да

а откуда?

Одесса

а откуда?

Ну лично я

Да

И у каждого элемента уникальный ид? И индекс?

И у каждого элемента уникальный ид? И индекс?

Вроде того

Вроде того

И отношения? С чем?

норм :) я с киева

И у каждого элемента уникальный ид? И индекс?

С анализом и максимально быстрой реакцией

С анализом и максимально быстрой реакцией

Анализ и реакция это другое. Парсить на эту тему можно хоть чем

И отношения? С чем?

С устройством, с которого пришли логи. С компанией устройства. С залогиненным в системе пользователем.

С устройством, с которого пришли логи. С компанией устройства. С залогиненным в системе пользователем.

На редисе? Реляции? Понятно.

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

На редисе? Реляции? Понятно.

Где я сказал о редисе?

И РедШит

А кто редис с постгресом сравнивал?

Я.

Редшит это просто как купить вместо 1 сервера 10

Задавить проблему экстенсивно

Я.

Зачем тебе все это?

Философский вопрос - зачем так жить? ;)

И куда мы все катимся?

Cap теорема не спит, чудес не бывает

Хотите писать логи быстро - не пишите их в обычную rdbms

Ну так эта теорема опять же об общем теоретическом случае. Всегда можно найти частные случаи в которых ее можно победить )

Хотите писать логи быстро - не пишите их в обычную rdbms

Все зависит от задачь

Вот логи. Они всегда констстентны КПК ч понимаю. Этим можно пользоваться и писать их тупо в распределеный файл

Вот логи. Они всегда констстентны КПК ч понимаю. Этим можно пользоваться и писать их тупо в распределеный файл

Нет, не все :)

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

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

+1

Все зависит от задачь

Или быстро или в индекс и диск. Другого не дано. Волшебная редиска просто не может в реляции видимо

Эти записи не только обладают свойством логов, но и еще используются как данные для выборки, то есть это не на 100% логи.

ERROR: S client not available

Эти записи не только обладают свойством логов, но и еще используются как данные для выборки, то есть это не на 100% логи.

Как часто?

Ну он же тебе пишет, что при каждой вставке :) Насколько я понял.

Как часто?

Что как часто?

Что как часто?

Используются

После вставки требуется анализ, максимально быстро.

И решение требовалось как всегда, на вчера.

Ну и проблему вы не решили как я понял

Решили

Решили

Купив облако?

Нет

А как?

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

На амазоне временно взяли РедШит, а после переписали.

И в этом им помог ORM, если разворачивать стек наших обсуждений )

Ну и ладненько тогда

И в этом им помог ORM, если разворачивать стек наших обсуждений )

Не помешал.

И в этом им помог ORM, если разворачивать стек наших обсуждений )

Именно

Слушайте, а есть где-то пример цикличной работы нескольких файберов? К ним обязательно event loop надо прикручивать, или можно их простейшим циклом перебирать?

Слушайте, а есть где-то пример цикличной работы нескольких файберов? К ним обязательно event loop надо прикручивать, или можно их простейшим циклом перебирать?

Есть же отложенное выполнение. Плодишь файберы сразу присваивая будущий результат куда надо в любых количествах.

http://www.opennet.ru/opennews/art.shtml?num=46781

Я хотел реализовать работу с многими сокетами через них. Я так понимаю мне надо в файбере просто описать логику чтения/записи в сокет, а потом извне сделать цикл somefiber.call() до тех пор пока его состояние не станет Fiber.State.TERM ?

http://www.opennet.ru/opennews/art.shtml?num=46781

Что за контора?

Я хотел реализовать работу с многими сокетами через них. Я так понимаю мне надо в файбере просто описать логику чтения/записи в сокет, а потом извне сделать цикл somefiber.call() до тех пор пока его состояние не станет Fiber.State.TERM ?

Сервер? Файберы лишние имхо

Без понятия. Попалась интересная статья, поделился.

Сервер? Файберы лишние имхо

А что лучше взять? Просто через socket_select обрабатывать все в одном линейном потоке?

Канеш

Ну тоже вариант, но это как-то не очень читабельно будет КМК

Как напишешь. Зато не будет проц жрать.

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

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

Это уже произошло или планы? А то может выкинуть dcd...

Не знаю, тут обсуждали мельком. Скорее всего не произошло. В мире D ничего не происходит вот так сразу :)

Это все будет допиливаться годами