Aw
Один терабайт
если терик, то просто я бы взал постгрес, отреплицировал на несколько нод с шардингом и прикрутил помимо ключевых индексов триграмовский на твой блоб
Aw
оно где-то в 3 ТБ получится сумарно, зато выборка и поиск быстрый будет
Aw
Если у тебя в блобах картинки. тогда есесно триграмовского индекса на на них не нужно
Aw
Вообще. по правильному. тут нужно просто обыкновенное хранилище с резервированием zfs и крошечная БД. которая хранит пути до каждого файла в хранилище
Aw
хранить блобы в БД - зло. причем неистребимое
Aw
Почему зло то?
Потому что БД , реляционные создавались для хранения маленьких кортежей, строчек в таблице. для эффективного поиска по ним. Блоб ввели на случай данных, которые нельзя было реализовать типами, которые уже есть. Хранить картинки по мегобайту, - это сразу дикая фрагментация в БД. И она превращается по скорости по сути в обыкновенный файл
Aw
ZFS - как раз для этой задачи.
Aw
с индексом по именам файлов и путям в какой нить бд
Дмитрий Харитонов
ZFS - как раз для этой задачи.
Почему именно zfs? Не лучше тут сразу что-то кластерное?
RafaelRS
Потому что БД , реляционные создавались для хранения маленьких кортежей, строчек в таблице. для эффективного поиска по ним. Блоб ввели на случай данных, которые нельзя было реализовать типами, которые уже есть. Хранить картинки по мегобайту, - это сразу дикая фрагментация в БД. И она превращается по скорости по сути в обыкновенный файл
Но хранение файлов отдельно - это тоже не есть удачное решение . ФС это неподконтрольная БД область, она не знает ничего о том, что какие то вещи собираются удалить, добавить. В итоге часто в таких БД можно встретить записи файлы к которым уже удалены по разным причинам
Aw
ну как вариант, что там бекапится и резервироваться может, то и подойдеит
Дмитрий Харитонов
Какой нибудь minio или другой аналог s3
Aw
Какой нибудь minio или другой аналог s3
я работал с hdfs, s3 хорошо работает только на серверах амазона
Aw
Ну если эти блобы например документы - то и смысла от этих 15 минут не будет, ибо самое важное то документы.
да, верно, а еще важно время, когда заказчику надо сейчас, ну пусть через час. а не через день
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
Насчет более жирного сервака - это уже от ситуации зависит и от насколько творчески к задаче подойти. Но в любом случае я и написал "и/или"
Явный прорыв - это конечно серверные SSD . Увеличивает эфективность очень хорошо. Но если было 8 ядер процессора. а купили сервак с 12 ядрами процессора, ускорение мизерное, а стоит в разы дороже.
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 питоне
Anonymous
Есть такое прр отруб да, но ты можешь нанести ему удар первым
ㅤ
Так а почему не GDM и его локер я так не пойму? 😊 На 100 Кб будет больше ОЗУ потреблять?
ㅤ
xscreensaver несекрюрный, глючный, как и lightdm.
ㅤ
Вот насчет сложнее это точно. Хотя может просто, но мы не знаем.
ㅤ
а есть чем заменить?
Что именно? Локер, заставочки на экрна из 90х, DM?
olegon.ru
ну выгорание все равно есть, да и в сон его постоянно загонять вредно?
Alexander "SonnySlave"
О_о
Alexander "SonnySlave"
очень интересно послушать
olegon.ru
ну как бы общеизвестно, что старт-стоп, включение и выключение для всех устройств вредно
Alexander "SonnySlave"
там написано ДЛЯ ВСЕХ
ㅤ
ну как бы общеизвестно, что старт-стоп, включение и выключение для всех устройств вредно
А палить столько электроэнергии впустую не вредно в масштабах планеты? Во всем мире это кстати понимают.
olegon.ru
правильно я понимаю, что в LED засветки черного быть не может? если засветка, то лампа?
olegon.ru
у меня монитор старше :)
olegon.ru
потому и уточнил
olegon.ru
у меня два каких-то достаточно старых NEC, вроде нормально...
olegon.ru
только вот с лампой или без - не знаю
olegon.ru
как бы еще определить, есть ли это мерцание или нет
ㅤ
правильно я понимаю, что в LED засветки черного быть не может? если засветка, то лампа?
Засветка и в LED мониторах может быть. И она есть повсеместно в современных бюджетных и не только.
ㅤ
как бы еще определить, есть ли это мерцание или нет
Включить вентилятор перед экраном, помахать карандашом, заснять на камеру телефона.
ㅤ
https://www.youtube.com/watch?v=IHKWQRzS2tE
olegon.ru
спасибо большое
olegon.ru
как раз собрался гуглить
ㅤ
Да незачно, про не всегда понятно что ты хочешь сказать или спросить. Лучше развернутый вопрос. :)
Anonymous
@xvitaly Мы тут скромным флудерским комунити во главе с Артемом создали флудилку-беседку для russianfedora, добавим в description сюда или в закреп?
ㅤ
@xvitaly Мы тут скромным флудерским комунити во главе с Артемом создали флудилку-беседку для russianfedora, добавим в description сюда или в закреп?
Не нужно. Просто если будет начинаться вакханалия можно написать что тема отличается от темы комнаты и продолжить можно там-то.
Anonymous
он же не админ ;)
Он такой не админ, как я админ ) надпись снял, типо ближе к народу )
Дима
Артем серый кардинал этого чата :-)
Дима
Правильное решение
CH1LL
Кто-нибудь использует серверную федору в продакшене? Как оно?
Aw
Или красношапка?
RafaelRS
Кто-нибудь использует серверную федору в продакшене? Как оно?
Если дома стоит, продакшном считается? :)))))
CH1LL
А центос чем не устраивает?
Вопрос не в выборе системы, вопрос именно в федорке. Любопытно как она себя ведет