а как объехать?

написать свой компилятор)) Вот как эти ребята http://www.highload.ru/2016/abstracts/2304.html

у нас порядка 6-7 тб всяких фоток

Я как-то работал с elliptics от яндекса как раз в качестве хранилки фоточек. Норм решение, по-моему.

Tempesta DB requires fallocate(2). Please use filesystems that support this system call, such as ext4, btrfs, or xfs.

у нас порядка 6-7 тб всяких фоток

Я уже подумывал предложить тебе у Даниила спросить об этом..

если соберетесь - скажите, я опубликую как есть в опенсорс свое хранилище

У нас там такое дикое древо в этой помойке, что пздц

большая вложенность(или глубокая) и что б дойти до какой-то фотки руками охуеешь,...

72млн фоток вроде как

Можно посчитать впринципе

Можно посчитать впринципе

ты опять репо убьешь, в бд 72 млн записей

😄

Окай

большая вложенность(или глубокая) и что б дойти до какой-то фотки руками охуеешь,...

зачем вы так?

ты опять репо убьешь, в бд 72 млн записей

Такс, погодика, а когда это я репо убивал?)))

зачем вы так?

Как?

Такс, погодика, а когда это я репо убивал?)))

ну я убивал ;)

зачем вы так?

да просто складывали складывали

И доскладывались

😄

Как?

с большим уровнем вложенности.

с большим уровнем вложенности.

Ну по другому хз как

Либо без вложенности

Все в одной папке

у вас фоточки модифицируются?

у вас фоточки модифицируются?

Залились и все, могут дергаться на просмотр не более

У нас там такое дикое древо в этой помойке, что пздц

ну в базе-то все плоское, в одном индексе

Залились и все, могут дергаться на просмотр не более

ну вот и славно. тогда стоит иметь какую-то статистику по их использованию

ну вот и славно. тогда стоит иметь какую-то статистику по их использованию

Нельзя удалять

Нельзя удалять

причём тут удаление?

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

тогда механизмы readahead в ядре будут рады

ну или просто популярный контент свалить в 1 каталог

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

плюсую. мы так отдавали 11ккк картинок.

ну или просто популярный контент свалить в 1 каталог

чтобы readdir(2) не подтягивал в dentry cache лишнее

плюсую. мы так отдавали 11ккк картинок.

склеить и хранить оффсеты? )

да

то есть append-only-сторадж, и иногда компакт

это очевидное решение )

более того, такая же схема используется в eblob у elliptics :)

чтобы readdir(2) не подтягивал в dentry cache лишнее

и бекапить это как?

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

Фоточки смотрят с range(забыл слово) в 2-5 месяцев

диапазон во

и бекапить это как?

что именно бэкапить?

что именно бэкапить?

отказоустойчивость обеспечивать

авторепликацию и ребалансинг

и бекапить это как?

А зачем бэкапиь? Берём рейндж фоток 6 месяцев, их закидывает в /repo, прошли 6 месяцев и 1 день фотка ушла в /repo2

только нужно тригер для бд сделать

что б запись перезаписывалась

Хм

Хотя я наверное несу хуйню как обычно

отказоустойчивость обеспечивать

а чем бэкап описанной мной схемы отличается от бэкапа простого хранения в файлах?

авторепликацию и ребалансинг

так же как и микрообъекты. только дешевле в сто раз.

микрообъекты мне реплицирует и ребалансит база. там все уже написано. а в этом методе как?

микрообъекты мне реплицирует и ребалансит база. там все уже написано. а в этом методе как?

погоди. какая база?

микрообъекты мне реплицирует и ребалансит база. там все уже написано. а в этом методе как?

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

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

я думаю, что Даниил ведёт речь про хранение всего в бд

погоди. какая база?

а какой шанс того, что одна фотка из-за race condition запишется на место другой?

а чем бэкап описанной мной схемы отличается от бэкапа простого хранения в файлах?

когда ты последний раз виделбекапер и, главное, восстановитель, файлопомойки на 10Т? вот представь - хранилище поломалось, восстановлению не подлежит. восстанавливаемся из бекапа? как быстро?

вот меня бекап больше всего волнует

а какой шанс того, что одна фотка из-за race condition запишется на место другой?

но как, Холмс?

но как, Холмс?

но такой шанс есть же

я думаю, что Даниил ведёт речь про хранение всего в бд

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

но такой шанс есть же

с чего бы вдруг*

?

а если радость не нужна - берем хранилище микрообъектов AKA clastered dbms, и радуемся

с чего бы вдруг*

у меня есть талант на такое нарываться

причём тут талант? у тебя на диске 100 файлов, ты их склеил в 1.

коллеги, скажите лучше, заводил ли кто-нибудь связку ubuntu 16.04+ansible+firewalld

причём тут талант? у тебя на диске 100 файлов, ты их склеил в 1.

их не 100, и пишутся они не из одного процесса

их не 100, и пишутся они не из одного процесса

их 10000 и они _уже_ записаны.

с чего бы вдруг*

Само захотело и сделало из-за ошибки в коде

Ошибку поправили, но ни как не вернуть обратно

компакт происходит на уже записанных данных.

их 10000 и они _уже_ записаны.

они еще не записаны, в том то и део

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

Хм,... нищеброды разговаривают о здравом уме

Норм

компакт происходит на уже записанных данных.

ну - мы написали сторедж cassandra

да, оно там примерно так же и происходит.

еще кой-каких частей пока не написали, правда

коллеги, скажите лучше, заводил ли кто-нибудь связку ubuntu 16.04+ansible+firewalld

up