logtos: обычно отпаивал соседний - мерил и припаивал такой же :) с использованием нормального флюса и припоя. В даташитах к процессорам обычно есть описание обвязки, но для того что бы их получить нужно подписать NDA. Обычно, в таких случаях, проще обратится в сервисный центр intel'a за советом.
АртемЪ: для 5ГГц 802.11a 100мВт и 9dbi антенна со стеной панельного дома не всегда могут справится... Я собственно так и написал "У яблотехники, кроме макбуков конечно, банально не хватает чувствительности для него".
... на Сишке и дженерики макросами можно делать
Ok, в PostgreSQL и в Oracle тоже есть поддержка любых типов (иерархических и не только), проехали.
Эм... "реляционность" MongoDB это следствие использования B-tree в качестве индекса, но монга не ACID в общем понимании MVCC - нет полноценной атомарность и изоляции операций. по этому её часто называют "нереляционной", хотя на самом деле это не так... просто не более чем маркетинговая уловка и PR для привлечения инвестиций в далёком 2008ом.
Главным преимуществом монги в своё время являлась возможность вызова релятивных запросов и комманд с JS окружения, в том числе и с браузера - это позволило провести хорошую работу с сообществом (PR) и собрать толпу "верующих в масштабируемость /dev/null". Так что наличие SQL в монге угробило бы её как OpenSource продукт.
Конкретно в случае с "вставкой 5000 записей" - нужно нормализировать и нормально индексировать, денормализация в таком случае приведёт к значительной потере производительности.
Потому что если есть табличка (u64, varchar(255), varchar(255)) то для её обновния и вставки нужно на много больше времени (в 20-50 раз) чем для (u64, u64, u64), ну и индексы тоже проставить нужно... а индексация varchar'а - дело просто идиотское.
Дмитрий Авилов если у человека БД будет больше 60Гб - Redis не вариант...
Да и выборка с LSM-tree на хэштаблице не очень то и производительна (привет fusion-tree, привет Ван Емде Боас).
jonasas тут что-то не так... Лучше конечно взять и руками написать полнотекстовый поиск на Solr под конкретную задачу, чем городить Sphinx/Elastic.
Фильтр Блума не поможет избежать коллизий, но поможет определить их наличие и ввести дополнительную логику для обработки подобной, исключительной ситуации.
"java нерационально использует память" - тут всё зависит от прямоты рук и понимания подкопанной, "утечки" возможны и на Java. Бывает что нужно делать offheap кэширование, но это, скорее, исключение из правил. По поводу производительности сейчас ситуация не очень однозначна: Hotspot довольно продвинутая штука - большой разницы между ним и llvm'ом, после прогрева нет.
"Таблица нормализована максимально, чтобы не иметь каких-то релятивных зависимостей" - как это связано с понятием нормализации ?
Если нужно денормализировать - можно спокойно использовать индексированное материализованное представление. В общем профилировать, профилировать и ещё раз профилировать... а не разбрасываться фразами "JOIN-ы априори будут медленнее, чем их отсутствие" - для того что бы этого не было, нужно разобраться с индексацией под конкретные запросы и кэшированием в рамках самого планировщика СУБД.
Сформулируйте нормально вопрос.
"Нужно проверить после newer'a наличие файлов в потоке и изменить url (какой ?, где ?) подобным образом: url (До?) -> url (После?)"
GC (garbage collection) - сборка мусора, так как Unity выполняется в виртуальной машине. Да, по оптимизации большой плюс в сторону UE, и можно и по потребности самому полезть в ассемблер, а с Unity так не получится.
