Aw
Один терабайт
если терик, то просто я бы взал постгрес, отреплицировал на несколько нод с шардингом и прикрутил помимо ключевых индексов триграмовский на твой блоб
Aw
оно где-то в 3 ТБ получится сумарно, зато выборка и поиск быстрый будет
Aw
Если у тебя в блобах картинки. тогда есесно триграмовского индекса на на них не нужно
Aw
Вообще. по правильному. тут нужно просто обыкновенное хранилище с резервированием zfs и крошечная БД. которая хранит пути до каждого файла в хранилище
Aw
хранить блобы в БД - зло. причем неистребимое
RafaelRS
Aw
Почему зло то?
Потому что БД , реляционные создавались для хранения маленьких кортежей, строчек в таблице. для эффективного поиска по ним. Блоб ввели на случай данных, которые нельзя было реализовать типами, которые уже есть. Хранить картинки по мегобайту, - это сразу дикая фрагментация в БД. И она превращается по скорости по сути в обыкновенный файл
Aw
ZFS - как раз для этой задачи.
Aw
с индексом по именам файлов и путям в какой нить бд
RafaelRS
Aw
ну как вариант, что там бекапится и резервироваться может, то и подойдеит
Дмитрий Харитонов
Какой нибудь minio или другой аналог s3
Aw
RafaelRS
Aw
Aw
Все это реально уже пройденые шаги, и долгие миграции из СУБД в файловые хранилища вам предстоят ...
Aw
Если вариант с хранением логов и поиску по ним, тут уже блоб в субд хранить есть смысл. хотя бы потому что тектовый индекс можно сделать
Aw
А что там нынче в редхате про кластерные хранилища кажуть?
Aw
https://access.redhat.com/documentation/ru-ru/red_hat_enterprise_linux/5/html/cluster_suite_overview/s1-rhgfs-overview-CSO
Дмитрий Харитонов
Aw
вопрос во времени. Когда ты это делаешь в БД, выполняется много лишних операций.
Aw
При работе с ФС ничего лишнего, тупо по путям копируется и возможно еще и паралельно и распределенно
RafaelRS
Все это реально уже пройденые шаги, и долгие миграции из СУБД в файловые хранилища вам предстоят ...
Кому вам? Уж точно не мне. Для меня это уже пройденные времена. Скажу так, все зависит от конкретной ситуации. Вот например, на одной из прошлых работ была у нас БД от Exchange, на 200Гб. Да, жирно, да, обрабатывать долго, но картинки и прочие вложения - неотъемлемая часть важной переписки с клиентами включая крупные торговые сети, которую никак нельзя терять. Ничего не поделаешь, хочешь быстрее, делай быстрое хранилище и сервер. А то, хочу и жирные важные переписки хранить и иметь дохлый сервер - на двух стульях сидеть не получится. Одновременно в этой же компании была БД сервера 1С и без всяких изображений и блобов на 40-50 гигов. Вот там бы я категорически против был бы от хранения блобов в базе ибо самое важное там именно торговые документы и будет глупо ждать дольше восстановления из-за неважного баласта например картинок. Смотря что надо и настолько ли это надо что ты готов за это платить простоем и/или более жирным сервером.
Aw
Кому вам? Уж точно не мне. Для меня это уже пройденные времена. Скажу так, все зависит от конкретной ситуации. Вот например, на одной из прошлых работ была у нас БД от Exchange, на 200Гб. Да, жирно, да, обрабатывать долго, но картинки и прочие вложения - неотъемлемая часть важной переписки с клиентами включая крупные торговые сети, которую никак нельзя терять. Ничего не поделаешь, хочешь быстрее, делай быстрое хранилище и сервер. А то, хочу и жирные важные переписки хранить и иметь дохлый сервер - на двух стульях сидеть не получится. Одновременно в этой же компании была БД сервера 1С и без всяких изображений и блобов на 40-50 гигов. Вот там бы я категорически против был бы от хранения блобов в базе ибо самое важное там именно торговые документы и будет глупо ждать дольше восстановления из-за неважного баласта например картинок. Смотря что надо и настолько ли это надо что ты готов за это платить простоем и/или более жирным сервером.
Для стандартных задач есть стандартные решения. Если меняется описание задач. меняются и решения для них. Если все забили на глюконутость Exchenge, то это не значит, что это хорошо и правильно работает. А вот в 1С там это критично, время доступа к файлам и документам, вот и задумались над оптимизацией.
З.Ы. Более жирные сервера ситуацию не спасали, не спасут и не будут спасать. Сервер в 10 раз дороже текущего, даже на 10% быстрее будет редко работать, конечно не в разы. А вот оптимизация средств обработки и хранения практически за бесплатно может увеличивать эфективность намного. Конечно не надо вдаваться в магию и изучение манагерских презентаций с красивыми схемками, и скоростями работы, а все смотреть самому локально на тестовых данных.
RafaelRS
Насчет более жирного сервака - это уже от ситуации зависит и от насколько творчески к задаче подойти. Но в любом случае я и написал "и/или"
Aw
Типовое решение для CDN - XFS на линуксе с зеркальным рейдом и хранилищем путей в какой-нить СУБД (mySQL, MariaDB ...). вообщем которая хорошо реплицируется. Ну и по ночам прогонять срипты на вычещение потеряных ссылок из БД и на ФС, хотя обычно все забивают на это
Vasiliy Glazov
@xvitaly В чём проблема линковки LTO для i686? https://kojipkgs.fedoraproject.org//work/tasks/6027/34976027/build.log
Vasiliy Glazov
нуууу...
Vasiliy Glazov
но тут вряд ли проблема в gcc и памяти
Vasiliy Glazov
я вот такое ещё нашёл https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78034
Anonymous
А замеряли время сборки до и после оптимизаций? Чтоб хоть профит был во времени сборки
Anonymous
Так, а что он там оптимизирует тогда? По конечному результату
Anonymous
Честно говоря я сгорел почти сразу и поставил все апплеты от xfce
ㅤ
Копать нужно в сторону запуска gsd сервисов и будет проще и надженей что самое главное. Но это имхо.
ㅤ
Да и это вариант для тех кому еще пол гнома нужно.
Anonymous
Озаботься выбросом второго питона, у тебя 100% щас апплет блюпуп на 2 питоне
Anonymous
Я нашел ему аналог, но на 3
Anonymous
bluez blueman , он на 3 питоне
Alexander "SonnySlave"
Anonymous
Есть такое прр отруб да, но ты можешь нанести ему удар первым
ㅤ
Так а почему не GDM и его локер я так не пойму? 😊 На 100 Кб будет больше ОЗУ потреблять?
ㅤ
xscreensaver несекрюрный, глючный, как и lightdm.
ㅤ
Вот насчет сложнее это точно. Хотя может просто, но мы не знаем.
olegon.ru
olegon.ru
ну выгорание все равно есть, да и в сон его постоянно загонять вредно?
Alexander "SonnySlave"
Alexander "SonnySlave"
О_о
Alexander "SonnySlave"
очень интересно послушать
olegon.ru
ну как бы общеизвестно, что старт-стоп, включение и выключение для всех устройств вредно
Alexander "SonnySlave"
Alexander "SonnySlave"
там написано ДЛЯ ВСЕХ
olegon.ru
правильно я понимаю, что в LED засветки черного быть не может? если засветка, то лампа?
olegon.ru
у меня монитор старше :)
olegon.ru
потому и уточнил
olegon.ru
у меня два каких-то достаточно старых NEC, вроде нормально...
olegon.ru
только вот с лампой или без - не знаю
olegon.ru
как бы еще определить, есть ли это мерцание или нет
ㅤ
https://www.youtube.com/watch?v=IHKWQRzS2tE
olegon.ru
спасибо большое
olegon.ru
как раз собрался гуглить
ㅤ
Да незачно, про не всегда понятно что ты хочешь сказать или спросить. Лучше развернутый вопрос. :)
Anonymous
@xvitaly Мы тут скромным флудерским комунити во главе с Артемом создали флудилку-беседку для russianfedora, добавим в description сюда или в закреп?
ㅤ
Aleksei
Anonymous
он же не админ ;)
Он такой не админ, как я админ ) надпись снял, типо ближе к народу )
Дима
Артем серый кардинал этого чата :-)
Дима
Правильное решение
CH1LL
Кто-нибудь использует серверную федору в продакшене? Как оно?
Aw
Aw
Или красношапка?
RafaelRS
CH1LL