Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..., opennews (??), 19-Янв-20, (0) [смотреть все] +1 А задумка-то у автора не плохая, взял и решил проблему кластерных фс как 2х2 Ме, raver (ok), 21:53 , 19-Янв-20, (8) +8 // Зачем клиенту делать то, что из коробки делает HTTP 2 в канале и сама файловая с, xm (ok), 22:31 , 19-Янв-20, (9) +1 // Не в защите транспортного уровня дело, а чтобы предоставить такую возможность, х, syslinux (ok), 23:49 , 19-Янв-20, (10) // Шифровать это один вопрос, а сжатие - другой По поводу шифрования, если это хран, xm (ok), 00:04 , 20-Янв-20, (11) +1 А что сжатие - все тоже самое - сжали у себя конкретный файл или значение и отпр, syslinux (ok), 00:13 , 20-Янв-20, (12) Нет, всё не то же самое, потому что сжимать сжатое смысла, как правило, нет, как, xm (ok), 00:16 , 20-Янв-20, (14) а Вы посылаете текстовый файл 100KB , он запишется как есть, тип сжатия 0 посыл, syslinux (ok), 00:29 , 20-Янв-20, (15) –2 Беда нашего образования в том, что писать оно учит, а вот читать и, тем более, п, xm (ok), 00:38 , 20-Янв-20, (17) –1 Не все фс умеют сжимать Это опция, а не обязаловка Кому надо, будет использовать, syslinux (ok), 00:43 , 20-Янв-20, (18) –7 Не совсем понятно зачем серверу знать про компрессию если он всегда хранит файл , Sokoloff (?), 15:14 , 20-Янв-20, (29) gt оверквотинг удален Сделано будет просто для унификации как и с типом шифров, syslinux (ok), 15:32 , 21-Янв-20, (38) Так так оно и есть сейчас, за исключением того что хранилка будет получать от кл, syslinux (ok), 00:15 , 20-Янв-20, (13) –2 Попробуйте, там суть в том, что в каждой папке появляется свой bolt архив Нет с, syslinux (ok), 20:14 , 19-Янв-20, (3) +3 Можно в него какой-нибудь архив freedb запихнуть Там файлы меньше сектора на ди, Аноним (1), 19:25 , 19-Янв-20, (1) Любопытно, а зачем это здесь Тут к месту была бы асинхронность, kai3341 (ok), 20:02 , 19-Янв-20, (2) –2 // Оно на Go, там асинхронность то есть В сам болт архив все равно писать можно то, syslinux (ok), 20:18 , 19-Янв-20, (4) В зависимости от используемых стратегий синхронизации потоков, такой код априори, Аноним (6), 20:26 , 19-Янв-20, (6) // Практически описали рантайм Go Правда, они решили сосредоточиться на зеленых п, funny.falcon (?), 19:14 , 20-Янв-20, (34) BBolt - это mmap-ed хранилище В один тред не будет ни какой конкурентности при , funny.falcon (?), 19:13 , 20-Янв-20, (33) // GOMAXPROCS автоматом ставится по количеству CPU начиная с версии Go 1 5 Как бы,, syslinux (ok), 17:37 , 21-Янв-20, (47) в общем, понятно - у них лопнула moosefs совершенно не предназначенная для тако, Аноним (5), 20:20 , 19-Янв-20, (5) –1 // Надо потестить, судя по опциям там таймауты то есть чтобы наружу ставить, но там, ala (?), 20:44 , 19-Янв-20, (7) +1 Использую для аналогичного sea weedfs, уже несколько лет работает в проде не б, n80 (?), 00:33 , 20-Янв-20, (16) +1 // И как оно Мы в свое время побоялись её на прод пускать С какими проблемами при, Аноним (26), 13:33 , 20-Янв-20, (26) // А чего бояться, тестировать надо и, пожалуй, хотя бы ознакомиться с кодом, благ, n80 (?), 15:02 , 20-Янв-20, (28) // Спасибо На днях потестирую , Аноним (26), 18:38 , 20-Янв-20, (32) Я, может, чего-то не понимаю, но что мешает использовать в таком же режиме loop-, Аноним (19), 09:37 , 20-Янв-20, (19) +1 // то что ты, наверное, не хочешь создавать стопиццот loop-файлов вручную и обеспеч, Аноним (20), 09:46 , 20-Янв-20, (20) +1 // Не всегда базовую технологию можно выбирать Так что это костылик, позволяющий жи, Александр Литягин (?), 10:16 , 20-Янв-20, (21) // Ну насчет прям костылика я с вами не очень согласен, если вы читали todo, то там, syslinux (ok), 11:39 , 20-Янв-20, (24) Я что-то не понимаю - что мешает просто использовать ФС с tail packing и предост, Аноним (-), 11:38 , 20-Янв-20, (23) +1 // Это не ФС для начала, сравнение не корректное ФС не ограничивается одним или па, syslinux (ok), 11:42 , 20-Янв-20, (25) вероятно - то что раз люди вынуждены использовать moose - у них уже давным-давно, пох. (?), 15:41 , 21-Янв-20, (39) Для некоторых задач у ФС слишком большие по сравнению с такими специализированн, n80 (?), 15:14 , 20-Янв-20, (30) // А, и чуть не забыл у обычных ФС нет встроенной репликации между серверами Можн, n80 (?), 15:16 , 20-Янв-20, (31) Так всякие raw-разделы ещё в OracleDB были Просто мне кажется, что если ты упира, Аноним (35), 22:40 , 20-Янв-20, (35) +1   // С OracleDB почти не имел дела, но сразу два момента 1 тут всё-таки про свободно, n80 (?), 03:00 , 21-Янв-20, (36)   Куда положить 250 млн картинок объемом 80 TB просто как пример В какую еще базу, syslinux (ok), 12:00 , 21-Янв-20, (37)   в оракловую, например Не вижу особых проблем, кроме цены решения Такая картинка, пох. (?), 15:45 , 21-Янв-20, (40)   В wZD 32 байта, оно хранится прямо в файле который заливается, память не исполь, syslinux (ok), 16:29 , 21-Янв-20, (42)   нет, мне было интересно именно для moose до переноса всего в архивы - чтобы пони, пох. (?), 16:49 , 21-Янв-20, (44)   Да, все верно Изначально был, потом убрал, чтобы он диски SSD мне не убивал Не , syslinux (ok), 17:12 , 21-Янв-20, (45) +1   gt оверквотинг удален , syslinux (ok), 17:20 , 21-Янв-20, (46)   Ну, для меня решение из этой новости или всё тот же SeaWeedFS 8212 тоже в опр, n80 (?), 16:22 , 21-Янв-20, (41)   Принял Спасибо за уточнение как вы делаете Значит предусмотрю изменение TTL бе, syslinux (ok), 16:36 , 21-Янв-20, (43)   Это для тех у кого ФС до сих пор не умеет в tail packing , Аноним (-), 11:37 , 20-Янв-20, (22) // Наверное, это для тех, кто в курсе минимального размера фрагмента суб блока и р, анонн (ok), 13:48 , 20-Янв-20, (27) +1 Завез я уже поддержку HTTPS, Keepalive, авторизацию per vhost, включение отключе, syslinux (ok), 07:45 , 23-Янв-20, (48) очень похоже на Grafana Loki Так же boltdb в качетсве хранения данных, только т, hes (?), 17:33 , 15-Янв-21, (51) 8,3,1,2,5,16,19,22,48,51

Сообщения

[Сортировка по времени | RSS]

	35. "Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."	+1 +/–
	Сообщение от Аноним (35), 20-Янв-20, 22:40
	>нельзя просто взять их и отключить Так всякие raw-разделы ещё в OracleDB были. Просто мне кажется, что если ты упираешься в ограничения ФС при работе с файлами - то ты что-то неправильно делаешь.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	36. "Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."	+/–
	Сообщение от n80 (?), 21-Янв-20, 03:00
	> Так всякие raw-разделы ещё в OracleDB были. С OracleDB почти не имел дела, но сразу два момента: 1) тут всё-таки про свободное ПО речь, это очень важный момент 2) низкие накладные расходы, легковесность, максимизация количества обрабатываемых простых запросов в единицу времени (по сравнению с конкурентами на таком же железе) — точно не про Oracle > Просто мне кажется, что если ты упираешься в ограничения ФС > при работе с файлами - то ты что-то неправильно делаешь. Полностью согласен. И вот один из путей перестать делать неправильно — положить данные в подходящую для задачи специализированную СУБД, а не в отдельные файлы в ФС общего назначения. О том и речь.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."	+/–
	Сообщение от syslinux (ok), 21-Янв-20, 12:00
	Куда положить 250 млн картинок объемом 80 TB просто как пример? В какую еще базу? Кто утверждает, что такое количество допустим должно быть обязательно в фс общего назначения, про кластерные забыли? Там писал один человек, что moosefs лопнула, не лопнула, она нормально впринципе работает с такими количествами файлов, если у вас есть деньги на оперативную память, но вот ее CRC проверка фоновая проводится несколько месяцев на таких количествах, а она там однопоточная и это не регулируется. Доводить до половины миллиарда файлов или больше уже нет смысла в ней. Вам дали способ - как упростить себе жизнь не изменяя файловую систему на какие-то решения, которые еще неизвестно как себя поведут(в плане фс изначально), в том числе оставлена без изменений работа с большими файлами, не надо заботится о волюмах, изменять пути в приложении, и прочие вещи. Кстати на счет SeaWeedFS - вы писали там есть TTL, что может быть удобно в некоторых случаях. Я сделаю у себя такую поддержку.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."	+/–
	Сообщение от пох. (?), 21-Янв-20, 15:45
	> Куда положить 250 млн картинок объемом 80 TB просто как пример? В какую еще базу? в оракловую, например. Не вижу особых проблем, кроме цены решения. Такая картинка - отличный blob (не очень-то и 'l'), причем ее метаданные если есть - абсолютно перпендикулярны типовым для файловой системы (в последнюю очередь, полагаю, вас интересует ее atime с точностью до микросекунды), и вы их все равно в какой-то тазе банных храните ведь? И да, орацл умеет в кластеры ;-) btw - сколько на самом деле жрет памяти на metadata и какого объема логи на логсерверах, если не жалко?
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."	+/–
	Сообщение от syslinux (ok), 21-Янв-20, 16:29
	>> Куда положить 250 млн картинок объемом 80 TB просто как пример? В какую еще базу? > И да, орацл умеет в кластеры ;-) > btw - сколько на самом деле жрет памяти на metadata и какого > объема логи на логсерверах, если не жалко? В wZD? 32 байта, оно хранится прямо в файле который заливается, память не используется. Из которых 8 байт зарезервировано под будущий дистрибьютор. Логи тут не нужны. Мне уже не нужно никакое решение, я уже все что надо сделал без любой бд. В MooseFS на оставшиеся 10млн файлов после архивирования потребляется 8GB RAM всего с учетом директорий, а было 75GB+.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."	+/–
	Сообщение от пох. (?), 21-Янв-20, 16:49
	нет, мне было интересно именно для moose до переноса всего в архивы - чтобы понимать, на каких масштабах оно таки лопается. 250миллионов файликов = 75G оперативы, я правильно понял? А что при этом происходило на металоггере, или вы ими не пользовались?
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."	+1 +/–
	Сообщение от syslinux (ok), 21-Янв-20, 17:12
	> нет, мне было интересно именно для moose до переноса всего в архивы > - чтобы понимать, на каких масштабах оно таки лопается. > 250миллионов файликов = 75G оперативы, я правильно понял? > А что при этом происходило на металоггере, или вы ими не пользовались? Да, все верно. Изначально был, потом убрал, чтобы он диски SSD мне не убивал. Не вспомню как он работал, когда было 150млн файлов, но в память точно все помещалось. У меня по 128GB было на серверах, где была пара металоггеров. Теперь вернул естесственно обратно. Я думаю MooseFS то не лопнет и на 500млн файлов, но при условии что у вас будет порядка 30-50млн подпапкок, где файлов по 10-1000 примерно, но все равно скорость то будет помедленнее. А вот если у вас 500млн файлов и 1млн подпапок всего, тогда это все будет уже гораздо хуже работать. Ведь MooseFS создает индексы частями в памяти чтобы искать сразу по нужным массивчикам. Чем меньше папок и больше файлов, тем больше сами массивы, тем хуже все работает. Но я уже не рискнул бы доводить до таких объемов у себя, просто потому что и запускается дольше и CRC долго чекает итп итд.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."	+/–
	Сообщение от syslinux (ok), 21-Янв-20, 17:20
	>[оверквотинг удален] > была пара металоггеров. Теперь вернул естесственно обратно. > Я думаю MooseFS то не лопнет и на 500млн файлов, но при > условии что у вас будет порядка 30-50млн подпапкок, где файлов по > 10-1000 примерно, но все равно скорость то будет помедленнее. А вот > если у вас 500млн файлов и 1млн подпапок всего, тогда это > все будет уже гораздо хуже работать. Ведь MooseFS создает индексы частями > в памяти чтобы искать сразу по нужным массивчикам. Чем меньше папок > и больше файлов, тем больше сами массивы, тем хуже все работает. > Но я уже не рискнул бы доводить до таких объемов у себя, просто > потому что и запускается дольше и CRC долго чекает итп итд.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."	+/–
	Сообщение от n80 (?), 21-Янв-20, 16:22
	> Куда положить 250 млн картинок объемом 80 TB просто как пример? В какую еще базу? Ну, для меня решение из этой новости или всё тот же SeaWeedFS — тоже в определённом смысле СУБД. Так что база в этом смысле. Если что, я тут нигде не топил за ненужность сабжа, напротив, пишу о причинах по которым такие решения нужны и возникают. > Кто утверждает, что такое количество допустим должно быть обязательно в фс общего > назначения, про кластерные забыли? Не суть, имелись в виду ФС, как бы так сказать, совместимые с POSIX-семантикой. Которым противопоставляется специализированное решение, имеющее свои преимущества, в т.ч. за счёт отказа от всяких неиспользуемых функций. > Вам дали способ - как упростить себе жизнь не изменяя файловую систему > на какие-то решения, которые еще неизвестно как себя поведут (в плане фс > изначально), в том числе оставлена без изменений работа с большими файлами, > не надо заботится о волюмах, изменять пути в приложении, и прочие вещи. Я же разве против? Наоборот, всецело за. Разве что заботиться иногда всё-таки надо, это позволяет получить дополнительный выигрыш. > Кстати на счет SeaWeedFS - вы писали там есть TTL, что может > быть удобно в некоторых случаях. Я сделаю у себя такую поддержку. Наверное, уточню: в моём случае протухание по TTL реализовано внешним скриптом (потому что логика выбора удаляемых файлов немного нетривиальная), который посылает пачку запросов на удаление. Залить несколько миллионов файлов, потом продолжать потихоньку заливать файлы, а потом через сутки 2% самых старых из них удалить пачкой запросов — суровый такой стресс-тест. Более-менее традиционные ФС на удалении десятков тысяч мелких файлов ооочень крепко задумываются (иногда подвешивая вообще все операции ввода-вывода, пока журнал не прокачается).
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	43. "Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."	+/–
	Сообщение от syslinux (ok), 21-Янв-20, 16:36
	Принял. Спасибо за уточнение как вы делаете. Значит предусмотрю изменение TTL без перезаписи файлов. То есть не только вместе с файлом когда идет первоначальная заливка, но и потом чтобы можно было поменять TTL на другой или убрать TTL вовсе. Методом DELETE можно и внешним скриптом пользоваться как у Вас без поддержки встроенного TTL. На счет задумываться - да ФС имеют такие проблемы при очень массовых операциях. У меня в теории не должно быть проблем, не фс все-таки, принцип то примерно тот же как в SeaWeedFS, просто если думать волюмамим, то у меня волюмов столько сколько папок по сути, в них еще быстрее удаление будет работать. Я ни в коем случае не говорю Вам что мое чем-то лучше тоже, просто тема об одном, а уже Оракл сюда был приплетен. Да и я сомневаюсь что он нормально будет работать, там один индекс будет громадным, это надо тестировать сначала Оракл в таком ключе, а потом уже писать сюда, а то это просто предположение :) P.S. Просмотрел, это не Вы написали про Оракл изначально, другие комментаторы молодцы. SeaWeedFS тут совершенно корректно сравнивать, у меня решение зависимо конечно, в случае большого сторейджа, от обычных кластерных ФС на данный момент, но потом будет дистрибьютор и можно будет обходится и без кластерных ФС.
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема