Опять же, к выбору правильного инструмента. Я хочу сказать что в споре sql vs nosql у нас не два подхода. У нас их четыре, или даже пять (я уже не помню какая бд к каким относится), но casandra vs mongo vs redis vs mysql vs mysql + hs — это все разные вещи по архитектуре, у которых по разному с возможностями, которые разные по принципам работы с ними.
Многие выбирают какой-либо nosql инструмент только потому, что так делают другие (о, ребята из xxx используют yyy, круто, наверное и мне надо), даже не задумываясь о том, что бы посмотреть что либо еще. Либо задумываясь, но понимая что это — то еще болото, где никто ничего толком не знает, каждый тянет на себя одеяло и выбрать придется что-то одно…
К сожалению, реляционные базы данных давно уже стали тем самым «наиболее подходящим инструментом». Теперь даже для того, что бы просто хранить несколько десятков записей мы используем mysql/postgres и учим sql, хотя нам нужно SELECT * FROM entries where id = ?.
Но, благодаря тому, что интернет растет и развивается горадо быстрее нежели производительность рсубд, поставила этот спам на свое законное место… тоесть, к сожалению, еще пока нет, но я надеюсь в будущем все сложеться именно так.
К примеру сейчас в любом языке (в стандарной библиотеки) есть api для доступа ко всем популярным рсубд, но нет ни одного языка, где опять же, в стандартной библиотеки, есть api для доступа к любой из всех популярных nosql. Да и преподают у нас в учебных заведениях и теорию баз данных, где на первой лекции мы окунаемся в историю, на второй пробегаемся по зоопарку бд, и еще 20 лекций нам расхваливают как хорошо хранить данные в кортежах отношений (или как там это правильно зовется), мы много узнаем о том, что данные нужно не просто хранить, а нормализировать. Все 10 лабараторных — это конечно же работа с sql от microsoft.
Поэтому многие даже не знают из чег оможно выбирать.
Поэтому многие привыкли что данные хранятся именно так и никак иначе. Вот и требуют от nosql (опять же, nosql разный бывает: redis и mongo — это два совершенно разных подхода к хранению данных), чего-то невозможного.
Мой пример: социальные, мобильные и другие синглплеер игры, где необходимо отдать большую часть профиля игрока (домики, грядки, ачивки, квесты...).
То есть нам (в случае sql) необходимо сделать либо один запрос со множеством джойнов, либо несколько запросов и уже в коде объединять это все. Изменение-сохранение состояния, которое затрагивает множество объектов (построил дом — выполнил квест — получил награду и ачивку за выполнение 10 квестов) должно происходить атомарно. То есть
Как пришел: достаточно долгий путь борьмы с sql, схемой — иногда проще добавить еще один внешний ключ и выбирать по нему, сортируя все в коде, нежели отдавать эту роль базе данных. Сценарием использования: множество запросов или один но с множеством ждойнов, количеством бойлерплейт-кода и производительностью.
Постепенно начал задавася вопросом — а так ли необходимо хранить данные в десятке разных мест, ведь единственное преимущество такого хранения — централизованное изменение съемы.
Производительность с каждой неделей устраивала все меньше и меньше — счет пользователей идет на десятки тысяч, а данных в бд, строк в некоторых таблицах — на миллионы (и плевать по сути, что таблица представляет из себя три инта). Масштабирование sql — дело не из самых приятных. Появление в некоторых, особо «удачных» местах blob-ов спасало, но осадочек то оставался…
На чем остановился: mongodb, который немножко использовал сам, видел как используется в продакшне. В теории отлично подходил под наши требования: одна коллекция на все данные пользователя, атомарность чтения-записи, да и мы были в курсе, что если что можем потерять допустим некоторые последние изменения, то и ладно, главное что профиль цел и ничего дальше не поломается. Единственное что планировалось оставить на sql — логи, огромнейшее количество данных, которое невероятно важно для понимания что сейчас происходит в игре. Нет, конечно можно было и в монге их писать, но не думаю что mongo+sql так уж лучше чем postres + sql.
На практике же, когда эйфория прошла, реальность раставила все по своим местам — без разочарований, косяков, понимании того, что теперь некоторые вещи так просто и не сделаешь… естественно не обошлось. Но понимание того, что теперь можно не тратить время на то, что бы подумать как бы это все хранить, да так, что бы бд не загнулась, а просто писать код (сохраняя его в удобной форме для приложения, соответсвено) — вселяло чувство что путь мы выбрали правильный.
И на последок: Если при использовании рсубд мы очень не хотим что бы на наших замечательных графиках использование дисков базой ушло за сотню, то при использовании nosql решений в целом, а уж тем более монги в частности, нам необходимо смотреть на график памяти, потому что если ее не хватит, всем будет… нет, не маленький пушной зверек, но что-то очень близкое.
Разработчики монги решили, что если кончилась память, то лучше не упасть, а продолжать писать все на диск. В итоге падение производительности в несколько сотен раз, что в разы хуже любой рсубд и любой самописной тулзой. По ощущениям — монго откровенно намекает на то, что ей очень и очень плохо и просит вас придти к ней на помощь.
Прорабтал я там не долго (но это не моя вина...), На данный момент данной компании уже не существует (название было дурацким настолько, насколько оно может быть дурацким, что-то вроде digital lab). Было это году в 2008, позвал друг — стартап (правда за котором стояла одна небольшая нефтегазовая компания, если я не ошибаюсь), офис практически в центре москвы, который находился в одном из технологических помещений, но я уверен что это пошло только в плюс, учитывая количество дерева, стекла, освещения, кожанной мебели и imac-ов. Свой небольшой бар + кофе.
Одним словом дорого, пафосно и уютно. Что впрочем не удивительно, учитывая сколько денег на этой компании хотели поднять (как я помню в планах было написать один мега замечательный сервис который бы заменил и вконтакт, и рутуб и мейлру… и еще кучу всего). Дорого и пафосно — потому что любая мелочь выбиралась из раздяда — мы самые лучше и нам нужно все самое лучшее. Уютно — потому что над этим всем так же работал дизайнер интеръеров.
Закончилось кстати это все достаточно печально, компания «обанкротилась», мебель и техника ушла по руководству.
Но, во первых работать в этом месте хотелось — потому что все это создавало своеобразную атмосферу, которая очень даже мотивировала… это заметно было по всем разработчикам которые сидели в той комнате что и я ( у нас была своя комната в которой пуфиков и ковров было больше нежели в небольшом магазине).
К тому, что мне удалось поработать в подобном офисе, и вот что я хочу сказать: работать в таком офисе хочеться. Отвлекать может что-либо либо первые минут 20, пока не освоишься, либо когда работать не хочется вообще — правда в этой ситуации уже плевать какоой офис.
Но после такого офиса тяжело возвращатся к тому, что окружает нас в посведневной жизни — довольно тяжело.
С нетом проблем много и все они в мелочах. В прошлом году достаточно общался с разными людьми, одни переводили продукт с .net на java, другие изначально потратили немного времени и на стадии прототипа отказались от .net, в пользу java + ruby. Во всех случаях причиной перехода были ограничения платформы (лично я только в курсе, что нормальной алтернативы jms в .net нет, а что как там дальше — понятия не имею).
Меньшая облачность — это то, что я сходу могу назвать несколько облачных сервисов которые очень приятны, когда ты пишешь на яве или руби (тут вообще рай для разработчика), но когда дело касается нета и питона, то все тановиться куда печальнее
Действительно странно, я бы мог предположить, что .net не рассматривается из за достаточно слабой (по сравнению с java) интеграцией с другими сервисами и меншей облачностью, но опять же, у питона она гораздо хуже, но он присутствует.
Вот-вот, сейчас уже мирандой не пользуюсь. но примерно с полгода назад решил глянуть что там и как — немного ужаснулся, плагины которые работали у меня дома на доисторической версии… попросту не заводятся на одной из последних, и последнее их обновление было чуть ли не в 10-м году. И это не какие-то совсем уж нишевые плагины, а те, которыми пользовалось большинство народу — к примеру tabsrmm.
Меня такие ролики не мотивируют. Совершенно. Меня мотивирует то, как я себя ощущаю: Последние два года (до конца это весны), практически ничем не занимался — как итог прошлой осенью и этой зимой, спал много, было лениво все (хотя вес не менялся). Начались теплые деньки — велосипед, собак, тренажеры…
Сейчас сплю по шесть часов (и этого хватает), весь как-будто бы заведенный — мозги тоже начали лучше работать. И плевать что сейчас, в связи с нехваткой временем, занимаюсь как угодно — от трех, до одного раза в неделю.
+1 к физическим упражнениям, в конце весны-начале лета ежедневно катал по 20-30км на велосипеде, от этого ел еще больше, как итог к середине лета -5кг.
Не всегда выполнимое условие. Я вот как начал после качалки, еще году в 2005-м «нормально» питаться — все, могу хоть всю кастрюлю карбонары съесть (а это примерно 4 порции), а потом шоколадом или булочкой добить.
А по поводу сжигания жира, для меня самое лучшее, что было — 50-ти минутные занятия спиннингом.
throw hell какой-то, чем не угодило какое-либо исключение наследованое от RuntimeException с описанием того, в чем проблема. Да даже нет, не так, зачем в данной ситуации использовать checked exceptions?
Многие выбирают какой-либо nosql инструмент только потому, что так делают другие (о, ребята из xxx используют yyy, круто, наверное и мне надо), даже не задумываясь о том, что бы посмотреть что либо еще. Либо задумываясь, но понимая что это — то еще болото, где никто ничего толком не знает, каждый тянет на себя одеяло и выбрать придется что-то одно…
Но, благодаря тому, что интернет растет и развивается горадо быстрее нежели производительность рсубд, поставила этот спам на свое законное место… тоесть, к сожалению, еще пока нет, но я надеюсь в будущем все сложеться именно так.
К примеру сейчас в любом языке (в стандарной библиотеки) есть api для доступа ко всем популярным рсубд, но нет ни одного языка, где опять же, в стандартной библиотеки, есть api для доступа к любой из всех популярных nosql. Да и преподают у нас в учебных заведениях и теорию баз данных, где на первой лекции мы окунаемся в историю, на второй пробегаемся по зоопарку бд, и еще 20 лекций нам расхваливают как хорошо хранить данные в кортежах отношений (или как там это правильно зовется), мы много узнаем о том, что данные нужно не просто хранить, а нормализировать. Все 10 лабараторных — это конечно же работа с sql от microsoft.
Поэтому многие даже не знают из чег оможно выбирать.
Поэтому многие привыкли что данные хранятся именно так и никак иначе. Вот и требуют от nosql (опять же, nosql разный бывает: redis и mongo — это два совершенно разных подхода к хранению данных), чего-то невозможного.
То есть нам (в случае sql) необходимо сделать либо один запрос со множеством джойнов, либо несколько запросов и уже в коде объединять это все. Изменение-сохранение состояния, которое затрагивает множество объектов (построил дом — выполнил квест — получил награду и ачивку за выполнение 10 квестов) должно происходить атомарно. То есть
Как пришел: достаточно долгий путь борьмы с sql, схемой — иногда проще добавить еще один внешний ключ и выбирать по нему, сортируя все в коде, нежели отдавать эту роль базе данных. Сценарием использования: множество запросов или один но с множеством ждойнов, количеством бойлерплейт-кода и производительностью.
Постепенно начал задавася вопросом — а так ли необходимо хранить данные в десятке разных мест, ведь единственное преимущество такого хранения — централизованное изменение съемы.
Производительность с каждой неделей устраивала все меньше и меньше — счет пользователей идет на десятки тысяч, а данных в бд, строк в некоторых таблицах — на миллионы (и плевать по сути, что таблица представляет из себя три инта). Масштабирование sql — дело не из самых приятных. Появление в некоторых, особо «удачных» местах blob-ов спасало, но осадочек то оставался…
На чем остановился: mongodb, который немножко использовал сам, видел как используется в продакшне. В теории отлично подходил под наши требования: одна коллекция на все данные пользователя, атомарность чтения-записи, да и мы были в курсе, что если что можем потерять допустим некоторые последние изменения, то и ладно, главное что профиль цел и ничего дальше не поломается. Единственное что планировалось оставить на sql — логи, огромнейшее количество данных, которое невероятно важно для понимания что сейчас происходит в игре. Нет, конечно можно было и в монге их писать, но не думаю что mongo+sql так уж лучше чем postres + sql.
На практике же, когда эйфория прошла, реальность раставила все по своим местам — без разочарований, косяков, понимании того, что теперь некоторые вещи так просто и не сделаешь… естественно не обошлось. Но понимание того, что теперь можно не тратить время на то, что бы подумать как бы это все хранить, да так, что бы бд не загнулась, а просто писать код (сохраняя его в удобной форме для приложения, соответсвено) — вселяло чувство что путь мы выбрали правильный.
И на последок: Если при использовании рсубд мы очень не хотим что бы на наших замечательных графиках использование дисков базой ушло за сотню, то при использовании nosql решений в целом, а уж тем более монги в частности, нам необходимо смотреть на график памяти, потому что если ее не хватит, всем будет… нет, не маленький пушной зверек, но что-то очень близкое.
Разработчики монги решили, что если кончилась память, то лучше не упасть, а продолжать писать все на диск. В итоге падение производительности в несколько сотен раз, что в разы хуже любой рсубд и любой самописной тулзой. По ощущениям — монго откровенно намекает на то, что ей очень и очень плохо и просит вас придти к ней на помощь.
Одним словом дорого, пафосно и уютно. Что впрочем не удивительно, учитывая сколько денег на этой компании хотели поднять (как я помню в планах было написать один мега замечательный сервис который бы заменил и вконтакт, и рутуб и мейлру… и еще кучу всего). Дорого и пафосно — потому что любая мелочь выбиралась из раздяда — мы самые лучше и нам нужно все самое лучшее. Уютно — потому что над этим всем так же работал дизайнер интеръеров.
Закончилось кстати это все достаточно печально, компания «обанкротилась», мебель и техника ушла по руководству.
Но, во первых работать в этом месте хотелось — потому что все это создавало своеобразную атмосферу, которая очень даже мотивировала… это заметно было по всем разработчикам которые сидели в той комнате что и я ( у нас была своя комната в которой пуфиков и ковров было больше нежели в небольшом магазине).
Но после такого офиса тяжело возвращатся к тому, что окружает нас в посведневной жизни — довольно тяжело.
Как по вашему должен выглядеть мотивирующий офис?
Меньшая облачность — это то, что я сходу могу назвать несколько облачных сервисов которые очень приятны, когда ты пишешь на яве или руби (тут вообще рай для разработчика), но когда дело касается нета и питона, то все тановиться куда печальнее
Это кто вам такой бред сказал?
Сейчас сплю по шесть часов (и этого хватает), весь как-будто бы заведенный — мозги тоже начали лучше работать. И плевать что сейчас, в связи с нехваткой временем, занимаюсь как угодно — от трех, до одного раза в неделю.
Не всегда выполнимое условие. Я вот как начал после качалки, еще году в 2005-м «нормально» питаться — все, могу хоть всю кастрюлю карбонары съесть (а это примерно 4 порции), а потом шоколадом или булочкой добить.
А по поводу сжигания жира, для меня самое лучшее, что было — 50-ти минутные занятия спиннингом.