ryzhikovas

Почему вы все так спешите начать работать? Да еще и вместо обучения (каким бы оно ни было).

- У вас еще впереди лет 30-40 работы, большую часть жизни вам придется работать. Вероятность того, что вы все эти 30 лет будете работать в удовольствие далеко не 100%.
- Начиная работать на 2-3 года раньше вам не дает сильных преимуществ в перспективе. В практически любой работе гораздо более важна эффективность, а не просто сколько времени вы проработали на определенной должности. Т.е. проработав, например, 5 лет, всегда найдутся люди с меньшим опытом которую делают вашу работу эффективнее (быстрее, качественнее)
- годы обучения в ВУЗе для очень многих людей являются самыми счастливыми, а во многих случаях даже формируют фундамент всей оставшейся жизни: друзья, хобби, знакомства, связи, какие-то ключевые события. Сидя 8 часов в офисе в день на работе или в квартире на фрилансе вы все это упустите скорей всего.
- во время учебы у вас есть масса времени попробовать поработать в разных местах и сферах: backend, frontend, мобильная разработка, дизайн, попробовать заняться научной деятельностью, попробовать что либо вообще не связанное с IT. После нескольких лет работы вы только будете мечтать о таком, но времени и возможности сменить радикально сферу работы вы не сможете просто.

ps ну нахрена вам деньги в 17 лет? Машину купить? Бабу свою свозить в Европу? iMac за 100 тысяч купить? Это все вещи которые не стоят вашего времени как минимум 17 лет точно.

Лично я склоняюсь к БД. Например, SQLite. Только, естественно, не одним файлом, а разбить на "блоки". Идею можно посмотреть в SAS.Планете (кэш BerkeleyDB) или в SACS, там прямо в SQLite есть кэш.

По поводу FS - не всякая система способна выдержать такую нагрузку (Windows XP и 50 миллионов файлов в кеше SASGIS), так что нужно смотреть на её тип и проверять под нагрузкой.

Если вопросов по надёжности FS не возникает и вы в ней уверены, то стоит рассмотреть вопрос бэкапов, а именно, удобство и скорость их создания и восстановления. Имхо, бэкапить миллионы тайлов очень неудобно, поэтому БД тут дадут фору.

Можно взять MongoDB, плюсы такие:
* При большой нагрузке или объеме можно будет данные разлить по шардингу. Это так же может помочь сэкономить, например можно вместо одного сервера DO за $480 можно взять 24 минимальных виртуалки за $120, + будет больше ядер и трафика.
* Можно хранить доп. параметры, теги, (атрибутивную информацию) и прочее вместе с файлом, таким образом тайл и все с ним связанное будет в одном блоке данных, в отличие от применения *sql. Это хорошо для производительности, т.к. меньше индексов и меньше обращений к ФС.
* Можно сделать доп. индексы
* Можно использовать гео-индексы, выборка тайлов по радиусу и т.п.
* Так же для данной задачи (вполне возможно) достаточно атомарных комитов, они лучше по производительности чем полноценные транзакции.

1. Пути к тайлам - в базе.
2. Картинки - в на диске с prefetching and caching в ОЗУ. По-скольку статика: nginx.
В принципе, нужно посчтитать: вполне возможно есть смысл при загрузке "холмы" (или всю матрицу тайлов) закинуть сразу в RAM-drive.
"Холмы": их вершины - это часто используемые тайлы. Как правило - это центры крупных городов (можно набрать статистикой использования).

Конечно ФС!
Только тут главное правильно распределить это дело =)
Т.е. не в одну папку сразу скидывать все 400Гб, а например по каким либо критериям (хоть по названию, хоть как).
Упс, пардон за очевидность, не прогрузился пост до конца.

База ведь так же хранит эти файлы на диске, причём sqlite - одним файлом .
В тонкости не вникал, т.к. мал ещё, но мне было проще распределять по файлам, возможно какие-либо оптимизации помогут.
Использовал xfs.
Плюс ещё в том, что можно в несколько потоков спокойно отображение делать.

Но Вы, наверное, это и так знаете, скорее всего ответ для таких как я =)

Можно посмотреть пример аналогичной библиотеки: BOOST::GIL. Может быть даже им и воспользоваться.

P.S. Хотя, толку от всех этих шаблонов не так много, как хотелось бы, больше проблем. На данный момент Boost::Gil мы уже не используем, есть собственный велосипед для работы с изображениями.

А почему не должен? Конструируется новый объект, а старый при этом будет удалён, но move конструктор как бы намекает, что не нужно использовать глубокое копирование в конструкторе. Нужно просто скопировать указатели и всё, при этом да, в исходном объекте указатели нужно обнулить. А в вашем случае от move конструктора толку вообще нет и не будет. Ибо нет никакого смысла в move конструкторе для примитивных типов, которые при этом создаются на стеке.

Насколько я понял идею std::move, вызов в return move(t) должен осуществить перемещение данных класса t в t1 без вызова деструктора.

Насколько я понимаю идею std::move, вы получаете вызов конструктора T(T&&) вместо T(const T&), в котором вы сами должны переместить (или не перемещать) нужные поля в создаваемый объект. После перемещения оригиналы полей нужно подходящим способом "обнулить". Деструктор локального объекта, выходящего из области видимости будет вызван в любом случае.

В реальной программе T содержит объект fstream, а в деструкторе осуществляется закрытие потока.

Насколько я вижу, std::fstream поддерживает конструирование из ссылки на rvalue.