Если уж нужно держать много данных в памяти, есть варианты «спрятать» их от сборщика мусора. Вот это библиотека в свое время сильно помогла https://github.com/rdp/google_hash
Имея опыт разработки на php, Ruby, Python и пр. пришлось окунуться в мир .Net, в частности MVC3.
По результатам 2 месяцев разработки и спустя реализованный проект сформировалось некоторое видение, чем я и хочу с вами поделиться.
Мнение чисто субъективное, я признаю, что я мог что-то не понять или понять не так.
Больше всего лучей поноса хочется послать в сторону Entity Framework.
Я использовал Code First подход. Описываешь модели, добавляешь их в контекст, немного магии, и оно все работает.
Но в текущей версии Entity Framework отсутствует понятие миграций базы данных, в виде привычном после рельсов и тд и тп.
Можно настроить пересоздание базы с чистого листа, при изменении в моделях, что терпимо на этапе разработки (если убить по дня на написание seed кода). В бою с этим вообще печаль.
Альтернативный подход это построить модели на основе готовой БД. И при каждом изменении структуры все весело перестраивать ручками.
И более всего поражают существенные различия в АПИ двух подходов, которые не позволяют безболезненно переключиться с одного подхода на другой.
ИМХО MVC это некая попытка вскочить на подножку проезжающего мимо поезда современных средств разработки (Rails, Django и т.д.)
Для .Net это может и является глотком свежего воздуха, но для меня многое кажется странным и пахнет индусами.
Сообщество и документация, наличие внятных примеров тоже оставляет желать лучшего.
Отличная штука. Скоро можно будет брать пару бутылочек пива, садиться на скамеечке возле парковки крупного магазина и любоваться потоком машин, пытающихся самостоятельно найти себе место для стоянки.
Группировка к примеру не работает на распределенных базах.
MapReduce пока работает в single-thread режиме, что не позволяет утилизировать более одного ядра и распараллелить как следует задачу. А вся соль MapReduce в том, что эти операции можно легко распараллеливать.
MongoDB не панацея. Да это может быть довольно эффективным решением на небольших кластерах. А когда речь идет о 1000 узлов, уже совершенно другой уровень монго в текущем его виде на мой взгляд еще большей геморрой чем в ручную шарденая sql база. Я думаю, сыроваты еще NoSql решения.
> А также препятствовать ограничению свободы пользователей в использовании контента или сервисов,
> кроме специфических пользовательских запросов.
Теперь осталось узнать, что именно будет пониматься как «специфический пользовательский запрос». Закон — законом, а подобные формулировки дают возможность всяким нормативным актам, внутренним инструкциям гос-органов трактовать все по своему.
В Ruby есть библиотека EventMachine как раз event-loop + неблокирующий IO. Есть веб-сервер thin использующий эту библиотеку. Для питона есть Twisted.
Если проект уже на питоне или руби то думаю лучше посмотреть в сторону их «родных» средств, чем плодить зоопарк из разных зверей)))
В фантастическом романе Вернора Винджа «Глубина в небе» описывались локализаторы. Крайне миниатюрное устройство, обладающее набором сенсоров (звук, свет и тд) и способное перезаряжаться от электромагнитных импульсов. При этом куча таких локализаторов, измеряя время прохождения сигнала между собой, определяла точное положение других в пространстве. Более того каждый обладал определенной вычислительной мощностью и сеть таких локализаторов становилась некислой вычислительной системой.
Ну и естественно были уже совсем фантастические фичи. К примеру, такой локализатор пристраивался рядом с глазным нервом, и мог передавать картинку, мог следить за биологическими показателями организма. В общем очень крутая штука, с довольно широким спектром применения, от простого позиционирования объектов, до тотального контроля над персоналом.
По результатам 2 месяцев разработки и спустя реализованный проект сформировалось некоторое видение, чем я и хочу с вами поделиться.
Мнение чисто субъективное, я признаю, что я мог что-то не понять или понять не так.
Больше всего лучей поноса хочется послать в сторону Entity Framework.
Я использовал Code First подход. Описываешь модели, добавляешь их в контекст, немного магии, и оно все работает.
Но в текущей версии Entity Framework отсутствует понятие миграций базы данных, в виде привычном после рельсов и тд и тп.
Можно настроить пересоздание базы с чистого листа, при изменении в моделях, что терпимо на этапе разработки (если убить по дня на написание seed кода). В бою с этим вообще печаль.
Альтернативный подход это построить модели на основе готовой БД. И при каждом изменении структуры все весело перестраивать ручками.
И более всего поражают существенные различия в АПИ двух подходов, которые не позволяют безболезненно переключиться с одного подхода на другой.
ИМХО MVC это некая попытка вскочить на подножку проезжающего мимо поезда современных средств разработки (Rails, Django и т.д.)
Для .Net это может и является глотком свежего воздуха, но для меня многое кажется странным и пахнет индусами.
Сообщество и документация, наличие внятных примеров тоже оставляет желать лучшего.
Хорошо хоть не кнопкой сброса суточного пробега или ручником.
Сколько трудов стоило прошивать ломать первые айфоны…
MapReduce пока работает в single-thread режиме, что не позволяет утилизировать более одного ядра и распараллелить как следует задачу. А вся соль MapReduce в том, что эти операции можно легко распараллеливать.
> кроме специфических пользовательских запросов.
Теперь осталось узнать, что именно будет пониматься как «специфический пользовательский запрос». Закон — законом, а подобные формулировки дают возможность всяким нормативным актам, внутренним инструкциям гос-органов трактовать все по своему.
Если проект уже на питоне или руби то думаю лучше посмотреть в сторону их «родных» средств, чем плодить зоопарк из разных зверей)))
Ну и естественно были уже совсем фантастические фичи. К примеру, такой локализатор пристраивался рядом с глазным нервом, и мог передавать картинку, мог следить за биологическими показателями организма. В общем очень крутая штука, с довольно широким спектром применения, от простого позиционирования объектов, до тотального контроля над персоналом.
ruby-doc.org/core-1.9/classes/Fiber.html
Так что есть из чего выбирать.
А вообще мне больше по душе EventMachine. Хотя писать через колбеки иногда не особо приятно.