А разве функционал кубов не реализуется поверх (с использованием) 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 библиотеки).
Вы неправильно строите вопрос, когда работаете с нейронными сетями… тип нейронной сети это не самый важный вопрос (хотя да, это тоже важно и определяет свой класс задач).
Проблема при использовании нейронных сетей не в выборе их типа и даже не выборе их параметров (количество узлов например), а в создании обучающей выборки.
Это не только нормализация данных, но и более сложная задача — выбор типа данных… можно тупо выдавать в сеть точек, а можно оформить в виде классов объектов (фигур) с парметрами, или например в виде растра и точек…
Пробуйте, перебирайте, исследуйте, тут я хз, нужна очень сложная математика чтобы хотя бы объяснить тот или иной выбор, причем для каждой задачи свой.
В своем проекте, обошел эти проблемы необычным но явно корявым способом:
* определил фиктивный корневой объект в datastore root, на который ссылаются почти все 'висячие' объекты (позволило использовать транзакции), часть объектов штатно определил потомками других.
* не использую Query вообще (благо задача позволяет обойтись сериализованными списками в полях или List)
* везде использую свои методы pm — getObjectById, makePersistent и deletePersistent, которые на время исполнения сервлета хранят все запрашиваемые объекты (повторно не запрашивает, если принудительно об этом не попросить) и выполняют окончательное сохранение (pm.Close, makePersistent и deletePersistent) по завершению (там же коммитится транзакция) — это позволило вообще обойти кучу ограничений и особенностей маппинга объектов к datastore, так как окончательная их запись будет произведена по выходу из сервлета.
p.s. сдерживаю потуги родить статью по своим решениям, но мне они кажутся нубскими (это вообще мой первый проект на Java, не считая helloworld под android) и почти наверняка использование какого-либо крутого (и само собой тяжелого) фреймворка смотрелось бы гораздо серьезнее. Как думаете, стоит?
обсуждения в этом направлении в разных системах уходят в туманные дебри недопонимания чего нужно и что можно…
Есть слабосвязанные задачи — контроль за балансом, мерчант и обменник (когда счет представлен в нескольких валютах).
* информация об изменении баланса — это текущие депозиты и список входящих и исходящих транзакций (эту информацию банки в лучшем случае представляют в человекочитаемом виде и по запросу, в ручную или в зависимости от крутости банка, в формате банка) — информации минимум, суммы и номера счетов участников.
* мерчант — надстройка, позволяющая запрашивать иннициацию транзакций (выписка 'счета'), их контроль (с привязкой к клиентам и сервисам) и отмену. Именно этого функционала в виде готового API не хватает у банков, а сторонние реализации будут должны оперировать долями своего счета со всеми вытекающими от сюда неудобствами, налогами и рисками. Единственная лазейка, которую различные сервисы используют, для того чтобы создавать мерчант на основе банковских счетов — это использование данных в особом формате в поле 'назначение платежа' (какой то прошлый век), и просить клиентов указывать абстрактные коды в это поле вручную.
* обменник — этот функционал имеет смысл так же в виде API если работать придется в интернациональном пространстве, в случае с корявым законодательством и отсутствии вменяемых международных договоренностей, почти нереально к возникновению, а в оффшорных зонах локальным клиентам не нужно.
Все в одном вместе могут предоставить только виртуальные (электронные) валюты, которые можно воспринимать как особый оффшор… и в текущих реализациях это просто дорого. Т.е. на лицо почти искусственно созданные условия по противодейтсвию развития банковской системы, потому и спросил — банки это делают специально или исключительно по скудоумию? Например почему вообще они (банки) вообще позволили появиться электронным деньгам — есть спрос на эти услуги, сам бог велел реализовать это на базе банка и захапать денежные потоки.