Проблемы начинаются когда вы используете библеотеку А и Б, потом нужно добавить библиотеку С, но внезапно она тоже использует библеотеку Б, только другой версии (скажем, старой). Придется собирать библиотеку С самому, добавлять ее в свой собственный Maven репозиторий. Когда придет время обновить библиотеки (например security issue где-то исправили или нужна новая функциональность или performance improvements, много может быть разных причин) то внезапно задача будет не тривиальной. Иногда даже код библиотеки С приходится править, т.к. в библиотеке Б сменился API.
Чем больше у вас Java библиотек в проекте, тем больше вероятность таких проблем.
Но вообще, похоже что вам важны только последние 3 месяца. В таком случае предлагаю писать каждый месяц в отдельную database внутри MongoDB. Потом удалять скопом DB целиком, будет очень быстро. Application layer нужно будет немного изменить, чтобы он делал 3 запроса (последние 3 месяца).
Теперь, с WiredTiger, «у него виртуальной памяти на 100Gb (не помню точно, но не мало)» — такого не будет. Потому что нет больше memory mapped files, которые раздували размер виртуальной памяти. Что касается файлов на диске — предлагаю попробовать и посмотреть. Потому что за это тоже отвечает WiredTiger и он работает совсем по-другому, не как MongoDB раньше.
нет, все гораздо лучше, т.к. теперь за это отвечает WiredTiger, нет больше никаких memory mapped files.
мы используем (и ненавидим) MongoDB в продакшене с самых первых версий, когда пришла пора искать подходящее хранилище со следующими параметрами: поиск только по ключу, random access (по настоящему random, никаких там working set fits in memory), размер данных много больше свободной памяти; написали по сути 4 data layer под наши данные: MongoDB, Cassandra, Riak, Aerospike. Залили живые данные. MongoDB тогда как раз вышла версия с optional WiredTiger, решили попробовать чтобы был так сказать baseline, ожидания были что MongoDB покажет себя хуже всех. В итоге MongoDB показала себя лучше всех. Riak был просто супер медленный, Aerospike был чуть быстрее MongoDB (совсем совсем чуть-чуть) но ел гораздо больше памяти, Cassandra по записи была хороша, но постоянный compaction весь read performance убивал совсем. Как то так. Эксперименты проводили на серверах, которые в итоге и использовались в production — AWS, 15G RAM (M3 General Purpose Extra Large), EBS optimized, EBS volume с базой 400 GiB, Volume Type gp2, IOPS 1200 / 3000
О! Помню эту статью, я автору огромный комментарий написал от всей души, а он мне ответил на него через несколько месяцев одной строчкой, которая противоречит его же постулатам из статьи. Если кто-нибудь категорически разделяет и понимает позицию автора, буду благодарен ответу на свои вопросы из оригинального комментария. Его легко найти внизу от оригинальной статьи, способа сделать ссылку на комментарий к сожалению не нашёл.
спасибо, не знал про такой контракт, сами мы с женой пользуемся T-Mobile, тем самым «секретным» prepaid за $30, может и имеет смысл перейти на Verizon, особенно если ещё у них телефон в lease взять
MySQL у них у всех как движок, данные скорее всего денормализованы и по 10 таблиц там для построения стены никто не джойнит, а таблицы шардят между несколькими серверами. YouTube тоже использует MySQL: github.com/youtube/vitess. Тоже не в третьей нормальной форме естественно. Twitter использует разные хранилища исторически (MySQL, Cassandra и другие), но переходят на свою разработку Manhattan blog.twitter.com/2014/manhattan-our-real-time-multi-tenant-distributed-database-for-twitter-scale.
Каждой задаче свой инструмент, бросаться использовать Cassanda или Manhattan для системы инвенторизации закупок, где у MySQL запас по производительности будет x100 даже без оптимизаций — смысла нет. Но когда на хабре плюсуют комментарии в духе «NoSQL придумали люди, не осилившие SQL» — это странно.
А что делать когда БД перестает умещаться на один самый большой сервер который вы можете себе позволить? Расскажите в Facebook или Twitter что их данные можно хранить в 3ей нормальной форме и спокойно делать джойны для чего угодно, только оптимизировать надо. А то они дураки там в твиттере какой-то манхеттен разрабатывают, наверно в универе их не научили уму-разуму.
Я не эксперт, но был на нескольких митапах по Go в San Francisco и задавал вопрос по generic'ам. Мой вольный пересказ: generics — это конструкция, которая повлияет на все другие аспекты языка — структуры, функции, методы, интерфейсы, каналы, пакеты — на все. На данный момент в языке все эти конструкции — ортогональны. Таким образом ввод generics сильно усложнит язык — как реализацию, так и использование. Также generics сами по себе — сложная вещь, есть подходить основательно (variance, type constraints). Разработчики Go не хотят вводить generics «чтобы было». Они пока не нашли решения, как можно ввести generics в go, чтобы это не навредило языку. Может и не найдут, но от generics окончательно и бесповоротно они не отказываются пока.
Это несущественная проблема. С точки зрения магазина, убытки от таких «недобросовестных» покупателей гораздо ниже стоимости внедрения и поддержки системы с отпечатками пальцев. И это еще если не учитывать отпугивающий фактор сканеров отпечатков пальцев.
Эту проблему проще решить возможностью копить баллы помимо скидки. Мало кто захочет копить баллы для чужой карточки, когда свою можно завести пряма здесь и сейчас и начать копить баллы для себя.
И вообще, мы чью проблему решаем? Если проблему клиента (много карточек — неудобно), то тогда номер телефона вполне решает проблему. Если проблему магазина (несколко человек могут использовать скидку) — то это другая проблема. Сканер отпечатков пальцев в таком случае — неплохое решение, видел как оно используется в тренажерном зале. В этой сфере — крупные сетевые тренажерные залы, бассейны и т.п. данная система может быть востребована, т.к. у них есть реальная проблема — они не хотят чтобы по цене абонемента на одного человека ходили 3 по очереди. Но у этой системы есть серьезный конкурент — карточка с фотографией.
Как люди иногда все усложняют. Проблема десятка дисконтных карточек решается очень просто. Вместе с карточкой клиенту предлагается ввести уникальный 10-ти значный знакомый ему номер, который он может всегда использовать вместо карточки. При оформлении карточки сотрудник магазина как бы невзначай говорит «чаще всего люди используют номер своего телефона».
ну вот абсолютно без контекта можно понять что происходит
Комментарии
// VarRefs() - это функция, определенная для ссылки на запрос (*Query) и возвращает массив ссылок ([]*VarRef)
func (q *Query) VarRefs() []*VarRef {
// если массив q.refs еще не вычислялся
if q.refs == nil {
// присваеваем пустой массив
q.refs = []*VarRef{}
// для каждого statement s из массива q.statements
for _, s := range q.statements {
// добавляем сссылки из s.VarRefs() в массив q.refs
q.refs = append(q.refs, s.VarRefs()...)
}
}
return q.refs
}
понятное дело что нужно знать синтаксис языка, но синтаксис Go простой, его изучить можно за 2 часа, и он очень близок к C
nullable нужен там где он нужен, где значение может быть нулевым, для этого есть en.wikipedia.org/wiki/Option_type
для каждого типа данных его лепить не нужно, также как не нужны магические значения -1 и т.п.
Для меня Rust и Go в разных лигах. Go хорош там, где раньше я бы воспользовался С или C++, для написания небольших утилит, но которые должны быстро выполняться, для веб-сервисов, БД и так далее. В общем на Go я бы с удовольствием писал такие проекты как Redis, MongoDB, или утилиты как scp, grep. Go это простой язык, в том плане что синтаксис очень простой, чтобы понимать код, не нужно знать контект. Go — императивный язык, shared memory model.
Rust же — это именно попытка скрестить C++ и Haskel. Это функциональный язык в первую очередь, вместо shared memory тут новая модель, где компилятор знает кто владеет памятью и контролирует доступ. Это очень очень интересная идея, надеюсь у них все получится. На Rust мне было бы интересно писать бизнес-логику, или machine learning системы.
Также Go — это уже взрослый язык, на горизонте версия 1.3, язык стабильный, в том плане что гарантирована компиляция ваших программ для всех 1.х версий языка. Go используют в продакшене давно и успешно. Есть куча библиотек для всего на свете и т.п.
Rust пока не достиг этого состояния. Это не плохо, это дает ему преимущество, потому что он все еще может кардинально улучшаться. Но для продакшена его использовать еще страшно. Mozilla например недавно представила Heka github.com/mozilla-services/heka — написан на Go, Rust они рассматривали в качестве кандидата, но отказались именно по причине его нестабильности (т.е. бурного развития)
Google купил не только компанию-производитель крутых термостатов для умного дома, но и Тони Феделла, и еще не известно, что сыграло большую роль. Цена сделки космическая. Сомневаюсь что Тони Феделл останется у руля Nest больше чем на год, скорее в будущем он возглавит более крупное подразделение Google. Интересно как все обернется, ведь в свое время он обещал с Apple не конкурировать.
Дисклеймер: праковаться в неположенных местах — хамство. Но аналогии они такие аналогии. Вы привыкли что около дома есть мусорные баки, из которых регулярно вывозят мусор. А теперь представьте что завтра все изменится. Рядом с вашим домом построят еще 4 многоэтажки, но контенеров для мусора не прибавится. А потом из 8ми контейнеров останется 3. Итог — когда вы с утра идете выкидывать мусор — баки переполнены и уже навалено рядом (хамами). Вы идете пару кварталов, чтобы выкинуть куда положено. Везде баки переполнены. И вот вы гуляете с мусором по окрестностям, уже 1.5 часа, вы же культурный человек. Вы опоздали на работу, ваш ребенок дома ждет когда же наконец его отведут в детский сад, но вы упорно продолжаете искать свободную мусорку.
И кого вы будете винить в сложившейся ситуации? Конечно тех, кто выкидывает много мусора. Конечно не тех, кто не подумал поставить больше контейнеров. В конце концов, нужно производить меньше мусора, и не забивать контейнеры своим, как последний хам.
Чем больше у вас Java библиотек в проекте, тем больше вероятность таких проблем.
мы используем (и ненавидим) MongoDB в продакшене с самых первых версий, когда пришла пора искать подходящее хранилище со следующими параметрами: поиск только по ключу, random access (по настоящему random, никаких там working set fits in memory), размер данных много больше свободной памяти; написали по сути 4 data layer под наши данные: MongoDB, Cassandra, Riak, Aerospike. Залили живые данные. MongoDB тогда как раз вышла версия с optional WiredTiger, решили попробовать чтобы был так сказать baseline, ожидания были что MongoDB покажет себя хуже всех. В итоге MongoDB показала себя лучше всех. Riak был просто супер медленный, Aerospike был чуть быстрее MongoDB (совсем совсем чуть-чуть) но ел гораздо больше памяти, Cassandra по записи была хороша, но постоянный compaction весь read performance убивал совсем. Как то так. Эксперименты проводили на серверах, которые в итоге и использовались в production — AWS, 15G RAM (M3 General Purpose Extra Large), EBS optimized, EBS volume с базой 400 GiB, Volume Type gp2, IOPS 1200 / 3000
Каждой задаче свой инструмент, бросаться использовать Cassanda или Manhattan для системы инвенторизации закупок, где у MySQL запас по производительности будет x100 даже без оптимизаций — смысла нет. Но когда на хабре плюсуют комментарии в духе «NoSQL придумали люди, не осилившие SQL» — это странно.
Эту проблему проще решить возможностью копить баллы помимо скидки. Мало кто захочет копить баллы для чужой карточки, когда свою можно завести пряма здесь и сейчас и начать копить баллы для себя.
И вообще, мы чью проблему решаем? Если проблему клиента (много карточек — неудобно), то тогда номер телефона вполне решает проблему. Если проблему магазина (несколко человек могут использовать скидку) — то это другая проблема. Сканер отпечатков пальцев в таком случае — неплохое решение, видел как оно используется в тренажерном зале. В этой сфере — крупные сетевые тренажерные залы, бассейны и т.п. данная система может быть востребована, т.к. у них есть реальная проблема — они не хотят чтобы по цене абонемента на одного человека ходили 3 по очереди. Но у этой системы есть серьезный конкурент — карточка с фотографией.
понятное дело что нужно знать синтаксис языка, но синтаксис Go простой, его изучить можно за 2 часа, и он очень близок к C
для каждого типа данных его лепить не нужно, также как не нужны магические значения -1 и т.п.
Rust же — это именно попытка скрестить C++ и Haskel. Это функциональный язык в первую очередь, вместо shared memory тут новая модель, где компилятор знает кто владеет памятью и контролирует доступ. Это очень очень интересная идея, надеюсь у них все получится. На Rust мне было бы интересно писать бизнес-логику, или machine learning системы.
Также Go — это уже взрослый язык, на горизонте версия 1.3, язык стабильный, в том плане что гарантирована компиляция ваших программ для всех 1.х версий языка. Go используют в продакшене давно и успешно. Есть куча библиотек для всего на свете и т.п.
Rust пока не достиг этого состояния. Это не плохо, это дает ему преимущество, потому что он все еще может кардинально улучшаться. Но для продакшена его использовать еще страшно. Mozilla например недавно представила Heka github.com/mozilla-services/heka — написан на Go, Rust они рассматривали в качестве кандидата, но отказались именно по причине его нестабильности (т.е. бурного развития)
И кого вы будете винить в сложившейся ситуации? Конечно тех, кто выкидывает много мусора. Конечно не тех, кто не подумал поставить больше контейнеров. В конце концов, нужно производить меньше мусора, и не забивать контейнеры своим, как последний хам.