Интересная статья.
Вопрос: какая стратегия все-таки используется для замещения картинок при наполнении сегмента — FIFO или LRU? И как механизм реализован? Вот эта фраза не очень понятна: если сегмент заполнен, линейным поиском по массиву ссылок находятся и удаляются из индекса ключи, чьи данные будут перезаписаны очередным блоком;
наверное подразумевается все-таки FIFO с указателем на текущую позицию для вставки, который при достижении конца сегмента сбрасывается на начало?
И если это FIFO, то не логичнее ли реализовать LRU, который позволил бы держать в кэше наиболее востребованные картинки?
Интересный пример. Правильно ли я понимаю, что в байткоде SubClass будет метод с сигнатурой public void setT (Object obj), в котором будет приведение входного параметра к Number? Почему-то всегда был уверен, что компилятор меняет сигнатуру для конечного типа.
Курс насколько отличается от Кормена? Практически все алгоритмы/структуры из первого курса изучил еще у Кормена, также почти все графы прочитал, но остальное из второго курса еще не изучал. Вопрос — насколько связаны второй и первый курс, тяжелее ли будет учиться, если я начну изучение со второго?
Абсолютно здравая мысль. Существующие NoSQL решения — в том числе и MongoDB — не выполняют и половины ACID свойств, попытки реализовать их искусственно выглядят нелепо и противоречат самой природе таких программных средств. С другой стороны, уверенность в том, что в распределенных системах консистентность (вкупе с высокой скоростью и доступностью, естественно) невозможна в принципе, тает после того, когда читаешь публикации Гугла об их Спаннере и F1.
Насколько понимаю, в МонгоДБ используется понятие кворума? Что будет с этой самой «транзакцией», если количество реплик будет равно или превышать сумму кворумов на изменение/чтение? Это ведь классический пример eventual consistency.
Ну, я не ставил целью рассмотреть плюсы и минусы NoSQL. Главная цель была — сгруппировать все характеристики и помочь новичкам создать себе представление о том, что такое NoSQL. По сравнению с стройными реляционными базами данных это — лес дремучий, даже для знающих людей. Слишком все стихийно и быстро развивается.
Я, кстати, не фанат NoSQL, мне больше по душе (да и опыта больше) дата гриды. Плюс распределенные базы данных еще не сказали свое слово, особенно в контексте последних успехов Гугла с F1 и Спаннером. Возможно, NoSQL базы стали предшественниками распределенных систем с консистентными операциями и мощью SQL в распределенных масштабах.
Плюс есть очень любопытные наработки в попытке скрестить распределенные хранилища с реляционными базами данных (HadoopDB).
Вопрос: какая стратегия все-таки используется для замещения картинок при наполнении сегмента — FIFO или LRU? И как механизм реализован? Вот эта фраза не очень понятна:
если сегмент заполнен, линейным поиском по массиву ссылок находятся и удаляются из индекса ключи, чьи данные будут перезаписаны очередным блоком;
наверное подразумевается все-таки FIFO с указателем на текущую позицию для вставки, который при достижении конца сегмента сбрасывается на начало?
И если это FIFO, то не логичнее ли реализовать LRU, который позволил бы держать в кэше наиболее востребованные картинки?
Насколько понимаю, в МонгоДБ используется понятие кворума? Что будет с этой самой «транзакцией», если количество реплик будет равно или превышать сумму кворумов на изменение/чтение? Это ведь классический пример eventual consistency.
Я, кстати, не фанат NoSQL, мне больше по душе (да и опыта больше) дата гриды. Плюс распределенные базы данных еще не сказали свое слово, особенно в контексте последних успехов Гугла с F1 и Спаннером. Возможно, NoSQL базы стали предшественниками распределенных систем с консистентными операциями и мощью SQL в распределенных масштабах.
Плюс есть очень любопытные наработки в попытке скрестить распределенные хранилища с реляционными базами данных (HadoopDB).
Статью почитаю на досуге, спасибо.