количество файлов не считала, по объемам было 15 терабайт медицинских raw данных

15Т? сколько было машин, если не секрет?

т.е. файлов в контейнере

15Т? сколько было машин, если не секрет?

8 :) и они были совмещены с компьютами nova для KVM

И не надо альтера :D

знаю Очень Большую ИТ-компнаию в России, в которой в БД хранился, в частности, IPv4-адрес сервера, на котором лежит конкретный файлик. апдейты при переезде серверов были веселейшим занятием.

жиза

У Зена вроде tdp меньше будет, чем у broadwell при тех же попугаях производительности, амд так говорит. Но с skylake они не сравнивали на презентации

Потому что нет аналогов на скайлейке пока. Впрочем вопрос в том как оно реально будет выглядеть

/repo/images/$name/$date/$id/$name_file.jpg /repo/images - сюда норм идёт /$name тут дохуя ( тут ls сделать нереально) /$date - начало от 01112012(тут вообще пиздец) /$name_file.jpg - просто название

/repo/images/$name/$date/$id/$name_file.jpg /repo/images - сюда норм идёт /$name тут дохуя ( тут ls сделать нереально) /$date - начало от 01112012(тут вообще пиздец) /$name_file.jpg - просто название

замените на хэши же. Такая структурная логика не нужна

Достаточно, что бы был скриптик, который всегда мог вернуть полный путь

на основе, не знаю, ID юзера скажем

этот путь хранится в бд, зачем ещё огород городить. Вопрос не про хеши и прочее..

Вопрос как зайти в какую-то конкретную папку

БД - точка отказа

Ой всё..

Хуёчка отказа

Похуй на бд как таковую

спакойна, Александр

Ниспакойна

тиха тиха )

всё хорошо )

Что за ересь про точку отказа, разговор вообще о другом

я даже могу предположить, каких именно файлов

Например?

у нас кстати тоже пути хранятся в бд

ну, лишний сервис, лишнее переусложнение. Лично я бы это сделала или на хэшах, если на фотки всем пофиг, или на swift, если потерять неприятно. Зачем тут реляционная БД не ясно

(для путей)

ну, лишний сервис, лишнее переусложнение. Лично я бы это сделала или на хэшах, если на фотки всем пофиг, или на swift, если потерять неприятно. Зачем тут реляционная БД не ясно

внутри свифта реляционная бд (:

да

=# select count(*) from media; count —------— 52627351

Сейчас бы повесеть это всё на скрипт..

52 млн записей..

Вопрос в другом, как ходить по этим папкам и как минимизировать время доступа к ним

Внутри ос, а не из базы, сайта и т.п.

По пути ходит хорошо, но пути мне не нужны, мне нужно что б я мог побегать по папкам на сервере.. а не ждать 40+++++++++++++++++++ минут что б ls равзернулся

Вопрос в другом, как ходить по этим папкам и как минимизировать время доступа к ним

чтобы у тебя ls в директории с 2 млн файлов отрабатывал быстрее?

чтобы у тебя ls в директории с 2 млн файлов отрабатывал быстрее?

Ну, там не 2 млн файлов

вложенность же

но да

хочу что б ходило норм

На данный момент это ебаный пиздец, я не представляю что будет потом..

а зачем?

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

зачем ходить?

тоже неясно

За надо, какая разница зачем?

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

Ещё раз повторю их не много

52млн

это уже много

напиши скрипт на питоне (могу я тебе написать, $30/hr, скорее всего нужно часа полтора),

и удаляй им

ахахаха

там свифт?

там свифт?

xfs если не перепутала Пони с кем-то ещё

а

/repo/images/$name/$date/ - тут делаю ls -l real 0m0.044s user 0m0.000s sys 0m0.000s

Опа нихуя, да?

чуть выше уровень тоже норм, а вот ещё выше

Там ебаный пиздец

этот ебаный пиздец у тебя в чем?

т.е. /repo/images/ - ls -l делался 40 минут и то я не стал ждать конца

ls тормозит в основном на сортировке, надо сказать.

ls -f и не дай бог тебе таб нажать

Да, это я понял, потом сделал ls - на 30 минутах тоже заебало ждать

:D

ls -f начнет плеваться в тебя списком сразу

насколько я знаю лукап-дентри

у тебя не будет это быстро

Да, это я понял, потом сделал ls - на 30 минутах тоже заебало ждать

Ксения тебе говорит совершенно верные слова про хеши и т.п.

ERROR: S client not available

А причём тут скрипты какие-то :D

Ещё раз повторю вопрос, причём тут скрипты и хеши?

У меня путь прямой ходит хорошо,

/repo/images/$name/$date/ - тут делаю ls -l real 0m0.044s user 0m0.000s sys 0m0.000s

не надо -l

не надо -l

дадада

Ещё раз повторю вопрос, причём тут скрипты и хеши?

при том, что количество вложенных уровней тоже можно хэшировать

Ещё раз повторю вопрос, причём тут скрипты и хеши?

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

это может быть остатком от деления, например

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

Мне нужно облегчить доступ именно средствами ос, без скриптов,.. скрипт я наговнокодить и сам могу

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

Мне нужно облегчить доступ именно средствами ос, без скриптов,.. скрипт я наговнокодить и сам могу

скрипт может возвращать тебе полный путь

Считать хэш,

НЕНУЖЕН МНЕ НИКАКОЙ ПУТЬ

а дальше ты сам средствами ОС

Пути у меня есть в базе

Блять

всё..

азбейте

Мне нужно облегчить доступ именно средствами ос, без скриптов,.. скрипт я наговнокодить и сам могу

извини. все ФС не очень работают, когда миллионы файлов на одном уровне. и, хм, select * from tbl where path like '/bla/huemoe/%' order by path desc; в твоей базе тоже будет выполняться довольно долго, в основном по причине большой величины списка.

извини. все ФС не очень работают, когда миллионы файлов на одном уровне. и, хм, select * from tbl where path like '/bla/huemoe/%' order by path desc; в твоей базе тоже будет выполняться довольно долго, в основном по причине большой величины списка.

Не тестил кстати, гляну тоже..

у Пони наверняка есть какой-то ID для каждого случая, например, ID юзера

Но postgresql работает в разы лучше, чем это было на mysql

И из него можно получить всё, что нужно

Но postgresql работает в разы лучше, чем это было на mysql

населектить это дешево, что в mysql, что в postgresql. печаль в том, что там данных - мегабайты. это не будет работать за 10 мс. ты покажи лучше time ls -f > /dev/null в этой директории

а то может нет у тебя никаких проблем.

населектить это дешево, что в mysql, что в postgresql. печаль в том, что там данных - мегабайты. это не будет работать за 10 мс. ты покажи лучше time ls -f > /dev/null в этой директории

сколько ждать? Час или два?

не всё ли равно в tmux или скрин:

?

ещё можно сделать же так: echo $(time ls.... 2>&1 ) | mail -s xolseg@yandex.ru (синтаксис не проверяла) ну и завтра тогда расскажешь

населектить это дешево, что в mysql, что в postgresql. печаль в том, что там данных - мегабайты. это не будет работать за 10 мс. ты покажи лучше time ls -f > /dev/null в этой директории

time ls -f > /dev/null real 2m6.859s user 0m0.028s sys 0m0.072s

time ls -f > /dev/null real 2m6.859s user 0m0.028s sys 0m0.072s

интересно

У меня путь прямой ходит хорошо,

почитай про сискал readdir()