p.s. кстати, я был готов реализовать работу с блоком через процедуры внутри самой БД, чтобы она же и следила за целостностью, но есть еще ряд требований, которые повысят сложность их реализации именно в БД
Охохо… это философский вопрос, мешать ли разные подходы к хранению данных sql/nosql или нет.
Маниакальное следование какой то одной парадигме в любом случае до добра не доводит. Не забываем, инструменты призваны помогать решать наши проблемы, а не создавать новые.
Ваяю сейчас небольшой проект… в одном основном бизнеспроцессе встречается сложный блок данных (который кстати будет активно апгрейдиться в будущем, это важно), который мог бы быть реализован в реляционной базе минимум десятью таблицами и сложными транзакциями, работа с блоком многопользовательская (но пользователей на блок мало, считанные единицы). Мне реально проще (во всех смыслах) вместо серии таблиц сериализовать эти данные в одном поле (не забывая про параметр 'версия', на будущее), а доступ к нему на чтение сделать блокируемым! Кода меньше на порядок, вероятность ошибки падает на порядок, данные несвязные, даже если будет ошибка, она будет локализована на конкретном поле а не всей таблице (ну это маловероятные ошибки, при обновлении можно пропустить дополнительное поле фильтрации, хотя я обычно стараюсь обновления делать только по PK)
Эээ… для речь ведь шла про не перелопачивание всей БД?!!! А после я привел похожее решение, но уже без сериализации.
json кстати для случая введения нового языка идеален… нет элемента в массиве — нет перевода, появится перевод, обновят поле. Все равно 'представление' обязано проверять, есть ли у поля соответствующее языковое значение например так isset('en').
Не дописал… вместо сериализации конечно можно почти автоматически скриптиком перелопатить базу, заменив все текстовые поля на следующие:
table{id,descr} -> table{id,en_descr,ru_descr,fr_descr,..}
Понятно что представление должно уметь работать с этими данными, подставляя текущий язык в имя параметра и проверяя, есть ли там значения (если нет, выдавать язык по умолчанию… или другое какое условие)
Вебкит сложнее установить на компьютерах ботнета, но конечно не невозможно.
Вы вынуждаете меня капитанствовать и повторять все вышесказанное другими, с чем я и так согласен, сохранить данные от копирования при одновременном предоставлении прямого доступа к ним — нереально сложная задача и не решается в общем случае.
Это вопрос времени и сил, которые могут быть кинуты на ее решение с обоих сторон (владельца и атакующих).
Во первых, многие облачные сервисы предоставляют бесплатные стартовые тарифы, для начинающих… например у амазона micro инстанс вообще бесплатен первый год!
Во вторых… 'миллионы мух не могут не ошибаться', не находите сходства?
Кстати! если требуется только найти одну точку пересечения, то можно неплохо с оптимизировать алгоритм, если проверку матриц выполнять не строго сверху вниз и слева направо, а определить хотя бы четыре стратегии и выбирать в соответствии со скоростями/направлением объектов (вычислять относительную), это конечно не гарантирует что точка пересечения будет найдена быстрее, но вероятность что нужная точка будет с краю — выше.
я вопрос задавал про тарифы… для 8-ядерного CPU взятого на вычисления, если они не нагружены на 100% плата списывается точно такая же как если бы они были загружены на все сто?
Еще вопросец, на сколько отличается 100% загруженный инстанс от не загруженного? И если отличается, то нагрузка на теслы так же разграничивается как и на процессоры?
К тому же я так понимаю там накручиваются копейки за трафик (вне кластера, а может и внутри, просто разные тарифы), работу с диском (кстати тот еще вопрос, занятый объем тоже чего то стоит)… с калькулятором там сам черт ногу сломит :(
Можно вопрос в догонку, тарификация инстансев ровно почасовая/поминутная/посекундная?, нет подводных камней вида, оплата почасовая но минимум месяц и т.п.?
Это почему у вас 768x768 ворочается медленнее чем многократно увеличенное количество кадров по 256x265?!!!
В вашем случае лучшее что можно сделать — увеличить размер кусочка карты… не больше размера экрана конечно же, если куски станут больше, то для отрисовки будет задействовано только четыре куска, что должно быть очень быстро (продумайте фоновую подзагрузку очередного куска заранее, например в направлении движения персонажа)
Извините, но возможности, доступные с этими аппаратами от Нокия, не далеко ушли от 'просто телефон' а дополнительный mp3-плеер выставляется как 'киллер фича'.
Лично я использую на телефоне единственное дополнение, что обеспечивает android — приложение для учета финансов, а так же я знаю, что если мне понадобится, скорее всего смогу больше, установив из маркета.
ext2/3 (и кажется и 4) каталоги — это просто файл с особым типом и тупым форматом (последовательность блоков под каждый файл), для поиска файла читается фактически весь список (конечно это быстрее чем вывести весь список, но трудоемкость такая же)
Если порыться, возможно можно будет найти файловые системы с древовидным хранением информации о файлах в каталоге.
p.s. поиграйтесь со squashfs, если запись критична — +unionfs или +aufs, в общих тестах (речь не идет о именно большом количестве файлов, формат контейнера squashfs так же планарный для директорий) дает в среднем 12%-30% прирост (тупо меньше елозить по диску)
Дано — тестовый контейнер или целый диск (500Гб)
1. Заполняем тестовый контейнер нулями (лучше СВОИМ блоком случайных данных, вероятность встретить которого в устанавливаемом образе минимальная)
2. Затем разворачиваем на этом контейнере систему штатным способом
3. Анализируем контейнер на изменения (просто посекторно сканируем на наличие своих блоков, сохраняя в своем файле измененные блоки (формат любой, например два файла — один блоки данных, другой — индекс вида [интервал->смещение в первом файле+размер,..] или если блок сделать большим, например в 1Мб, то [индекс блока ->смещение,..]).
4. Полученную информацию можно использовать для того чтобы быстро развернуть копию, записывая только измененные данные.
Данный механизм хоть и универсальный (работает с любыми проприетарными форматами, ему на них пофиг), но имеет смысл использовать только для случаев, когда целевое железо — одинаковое (типовое) и в принципе позволяет развертывание путем клонирования (как вы сказали у вас этот вариант подходит, просто грубое копирование — очень медленное).
Буквально только что потерял трое суток выходных из-за того что акронис ничего не предлагает сделать с поврежденным бакапом (по крайней мере это единственное объяснение, почему при попытке открыть бакап раздела акронис пишет файл не найден), а еще новые версии не могут работать архивами от старых… в общем грусть печаль и большой минус этой системе резервного копирования.
Хорошо что я параноик, у меня было три копии, разными средствами (просто важные файлы в архиве + ntbackup + acronis), плохо что это не позволило мне восстановить загрузочный раздел (не помогло даже установить чистую windows и поверх развернуть бакап, очень win7 этому препятствовало)
Серверные (консольные) инсталяторы, или называют еще часто alternative, имеют режим установки по сети (http/gtp) когда достаточно указать каталог в сети с распакованным cd и згрузиться с 5-10мб-ого загрузчика (когда то игрался с кучей дистрибутивов, возможно у debian stable поддержка такого режима установки осталась).
Скачано по сети будет ровно столько, сколько нужно для установки, от сотни мегабайт.