В файл писать не безопасно при многопоточном доступе (даже при дозаписи в конец, если блок данных достаточно большой, он может быть частично перезаписан следующим запросом), поэтому лучше пишите в БД, тем более для этого достаточно любой не транзакционной базы, хоть 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 объекта, не больше… и главное используются они в одном месте (там где описаны их функции) при рефакторинге изменить потребуется только там.
..в каждом методе писать global??? увольте, вообще сам факт существования global — ужас, но и запрет хранения в статичных переменных класса объектов сложнее строк и чисел тоже ужас, а создание методов на каждый чих — тоже ужас… (это реально, когда половина фактори-класса — описательная структура для доступа к другим объектам и спискам)
Выбор amd/intel среди процессоров, когда 'денег куры не клюют' определяют задачи и наличие оптимизированных под соотв. архитектуру средств/ПО.
автор, зачем вам материнская плата с 4 pci-e?
p.s. компьютеры, самый лучший способ выкинуть деньги… нигде так быстро не устаревает и не обесценивается товар
Редуктор сложное устройство, люфт шарниров зубчатой передачи и, самое главное, щели между зубьями соседних колец (а они будут всегда — создавая паузу при смене направления вращения)
Мерить видеокарты мегабайтами оставьте маркетологам… а тут разговор вести необходимо названиями процессора/ядра/серии…
По теме — не стоит гнаться за топовыми видеокартами, так как для расчетов их скорости растут не так быстро как качество/фичи рендеринга в играх, поэтому 58xx серия более чем достаточно, с ценами от 200$-300$ (необходимо удостовериться что нужные плагины поддерживают OpenCL — эта технология более универсальная и не привязана к типу процессора видеокарт, как CUDA — к NVIDIA, к тому же в расчетах именно ATI видеокарты лидируют в одном ценовом диапазоне).
Меньше 8гб оперативки — глупо, хотя некоторые из странных предубеждений не желают x64 операционку… а это ограничение в 3.5гб.
SSD — хотя бы под OS желателен, это вопрос не сколько возможностей, сколько комфорта, работа в photoshop больше творческая, и эмоции тут имеют большее значение (а эмоции от перехода HDD->SSD будут и положительные).
ага… я с похожим сталкивался, linux -> linux по smb доступ без пароля, а windows -> linux спокойно, все проблемы в разных методах организации аутентификации (share/workgroup/domain/..) и настройки порядка их выбора, где почитать, х.з. я слабоват в администрировании win, в windows можно начать копать с политик.
Не заметил что необходимо именно сжатие… но zip сжимает файлы по отдельности! вам нужен архиватор с возможностью использования общего словаря для нескольких файлов (это например как режим solid archive в rar).
Если нужна именно скорость, посмотрите в мир read only файловых систем, например squashfs (существуют opensource библиотеки).