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 поддержка такого режима установки осталась).
Скачано по сети будет ровно столько, сколько нужно для установки, от сотни мегабайт.
В файл писать не безопасно при многопоточном доступе (даже при дозаписи в конец, если блок данных достаточно большой, он может быть частично перезаписан следующим запросом), поэтому лучше пишите в БД, тем более для этого достаточно любой не транзакционной базы, хоть myisam в mysql (если будете создавать одну запись в одной таблице за один запрос)/
Я же не говорю о формате данных… нужны именно алгоритмы!
Чем мне поможет Apache Thrift? если именно его вызовы я собираюсь упаковывать, за счет повторяющихся данных в сообщениях, разнесенных во времени, а так же за счет 'лишней' информации в сообщениях, определенных их форматом (rpc — xml или json, если конечно не бинарный формат, который далеко не каждое приложение поддерживает, очень кушает трафик тупо за счет имен тегов и другой синтаксической обвязки).
У меня был пример где тупо на тегах и атрибутах уходило значительно больше половины трафика (я просто сравнил размер сообщения и объем данных в них, представленный в текстовом виде), особенно это заметно если параметры вызовов сложные структуры без текстовых данных, — таблицы и просто объекты с большим количеством полей.
Конечно в этом приложении мне не требовалось уменьшать трафик
А разве функционал кубов не реализуется поверх (с использованием) sql? я имею в виду как эти механизмы могут быть быстрее… тем более данная задача не очень то ложится на куб.
Только не уверен по поводу производительности на запрос данных из такого индекса, так как обычно они подразумевают использование индексированных выражений в where, group by и order by.
Если запись только добавление, то как написал выше — новую кеш-таблицу и обновляйте ее индексом — при добавлении записи (set sum_field2+=field2), при удалении соответственно (set sum_field2-=field2).
ruskar, ошибки в моем запросе нет, ты неверно понял идею.
При добавлении статьи ей присваивается номер равный +1 к номеру его последней (если статей не было то 0). При удалении статьи все номера для статей автора после удаляемой уменьшаются на 1.
p.s. Основная идея (ее почти всегда можно применять) — если запрос на чтение медленный, посчитаем его (или его часть) заранее во время записи.
ru.wikipedia.org/wiki/OnLive
Да, у них используется чип/плата собственного производства а так же используются системы виртуализации для запуска слабых игр на одном устройстве.
Для случая односторонней связи в качестве 'номера пароля' можно использовать текущее время, а синхранизировать время на в брелке и сигнализации — после успешной 'авторизации'.
Для сложных случаев (долго не пользовались — часы разошлись) оставить в брелке возможность ручной принудительно синхранизации времени — при физическом подключении.
Пароли не нужно хранить, достаточно генирировать. В сигналке и брелке вычисляется какой-либо криптостойкий хеш от времени (для особой надежности +соль) и при проверке — сравнивается.
p.s. этот алгоритм очень простой, не требует сложных вычислений (дешевое железо), не взламывается без одновременного физического доступа к брелку и сигналке и т.п. в общем одни плюсы.
Уважаемый оппонент, я вас понимаю, всем нравится sqlite, но я довольно внятно написал именно про время выполнения транзакций а не отдельных команд.
Я могу придумать тысячу и одно место применения sqlite, когда операции записи можно выполнять не заботясь о том, действительно ли они исполнены, чуть меньше — когда я могу назвать срок, в течении которого мне достаточно чтобы структура данных была не консистентна (отложенный коммит), но в общем случае мне выгоднее сменить бакенд на что то более быстрое, благо вариантов тьма, хоть тот же mysql embended.
p.s. для задач, когда записи редкие или отсутствуют — я бы первый рекомендовал sqlite, чтение реализовано вполне быстро (был проект, база доросла до 14гб, медленная последовательная запись и куча мелких поисковых запросов — одни только положительные впечатления)
Я кажется довольно ясно выразился, что именно необходимость писать global $base меня и не устраивает… ведь эту конструкцию приходится писать не в месте использования переменной, а в начале метода… и это можно забыть сделать (потенциальное место для ошибок).
Да, именно к таким базовым объектам как база данных таким образом я и обращаюсь… в глобальной области видимости у меня обычно 3-4 объекта, не больше… и главное используются они в одном месте (там где описаны их функции) при рефакторинге изменить потребуется только там.
Подскажите, это какие.