vasketsov писал(а):saasaa писал(а):миллионы файлов
Любую БД (СУБД, SQLite, Беркли).
А вообще при десятках миллионах тайлов надо уже эксперименты проводить в условиях, близких к реальным, чтобы оптимальный формат хранения выбрать и кучу оптимальных значений для кучи опций. Это уже не в хЪр собачий ))) и универсального рецепта тут быть не может (за исключением откидывания некоторых заведомо неоптимальных вариантов).
К сожалению, на больших кэшах (пара миллионов тайлов и выше) Беркли показывает себя крайне нежным и весьма падучим. Я качаю помногу и без перерыва, и (как-то начав качать напрямую в Беркли) - сейчас ~70-80% времени уходит не на скачку, а на проверку\починку уже наработанных баз. Это занимает примерно неделю в каждом конкретном разе, в течение которой закачка постоит и подождет.
Беркли-кэш падает часто, невнятно, по совершенно непонятным причинам, и чем больше кэша по объему - тем чаще он падает. Файлов ерроров при этом не создается. Самый распространенный вариант: САС качает прекрасно, потом в какой-то конкретный момент все окна закачек (
одновременно, и по всем качаемым
разным картам) останавливаются на стадии "Скачивание тайла...", САС начинает пожирать 99-100% процессорного времени, и на этом всё. Так стоять он может бесконечно, и штатный выход - не работает (САС просто тупо зависнет намертво). Выход - только по трем кнопкам, после трех кнопок - нужна проверка кэша (неделя), при которой ВСЕГДА обнаруживается около десятка битых баз. Лечение оных, рестарт закачек в сасе.......пара дней - сас на 100% CPU, и всё по кругу.
Менялись версии ночнушек, пытались делаться всякие твики и оптимизации - бестолку. Просто в какой-то момент Беркли срывает крышу, и скорее всего не на стадии привинчивания к САСу, а на стадии собственно беркли-базовода (оракловой ДЛЛки).
Для себя пришел к выводу, что БОЛЬШИЕ скачки нужно качать в старый, тайловый кэш - а по завершении процесса переносить в Беркли за раз, и потом делать его рид-онли.
На мелких кэшах проблем с Беркли не замечено.