25.12.2017 skynin 0

Designing Data-Intensive Applications (book)

Don’t just hack it together

NoSQL… Big Data… Scalability… CAP Theorem… Eventual Consistency… Sharding…

Nice buzzwords, but how does the stuff actually work?

As software engineers, we need to build applications that are reliable, scalable and maintainable in the long run. We need to understand the range of available tools and their trade-offs. For that, we have to dig deeper than buzzwords.

This book will help you navigate the diverse and fast-changing landscape of technologies for storing and processing data. We compare a broad variety of tools and approaches, so that you can see the strengths and weaknesses of each, and decide what’s best for your application

21.11.2016 skynin 0

MongoDB

После трех месяцев в разработке все прекрасно работало.

Но однажды в понедельник на планерке клиент сказал, что один из инвесторов хочет новую фичу.
Он хочет иметь возможность кликнуть на имя актера и посмотреть его карьеру в телесериалах.
Он хочет список всех эпизодов во всех сериалах в хронологическом порядке, в которых этот актер снимался.

Почему вы никогда не должны использовать MongoDB

из Почему эти ваши модные NoSQL решения не так уж хороши

Пробовали MongoDB. К счастью, с этой СУБД мне пришлось работать совсем недолго. MongoDB не выдерживает никакой критики, и ее недостатки, похоже, поняли уже все, кроме, разве что, самых упоротых программистов на Node.js. Вручную шардированный PostgreSQL, который, напомню, уже давно умеет формат JSONB, с самым тупым и никем не протестированным скриптом на Python для автофейловера, будет куда более удачным выбором, чем MongoDB. Подробности смотри у Афира и еще, например, вот тут. Выбрав PostgreSQL, вы получите все тоже самое, только куда более стабильное, не теряющее данные, а также с нормальными локами, вьюхами, транзакциями, джоинами и вот этим всем.

17.11.2016 skynin 0

Почему эти ваши модные NoSQL решения не так уж хороши

Тогда что же выбрать в качестве основной СУБД для нового проекта? Совет стандартный — возьмите любую РСУБД по вкусу. Если конкретнее, то я бы рекомендовал PostgreSQL, но в крайнем случае и какая-нибудь MariaDB, пожалуй, будет как минимум не хуже Монги. Затем масштабируйтесь вертикально до тех пор, пока это позволяет кошелек. Может так получиться, что для всего проекта вам будет достаточно одного сервера, плюс еще одной реплики для фейловера. Если это ваш случай, то вам крупно повезло, поздравляю! Иначе все тоже не так уж плохо, так как обычно 90% операций идут только на чтение, и их можно спокойно распределить по множеству реплик.

Вот если вы скоро упретесь на запись, только тогда следует подумать о разбиении базы данных на несколько, возможно, даже с шардингом. Хотя лучше обойтись без него, просто имея несколько совершенно независимых баз. К этому моменту вы уже будете хорошо понимать, что и куда можно перенести или как лучше пошардить, чего нельзя сказать о ранних этапах развития проекта. Также вы будете понимать, какие данные и в какое NoSQL решение можно перенести, если, конечно, в этом вообще есть смы

09.03.2016 skynin 0

Вьетнам компьютерной науки

объектно-реляционное отображение является Вьетнамом компьютерной науки. Это болото, в которое легко войти, но чем дальше, тем труднее продвигаться, и вскоре путники бредут, не видя никаких вешек, не зная своих шансов на успех и не имея никакой стратегии для выхода из болота

оригинал: http://citforum.ck.ua/database/articles/vietnam/

27.06.2006 skynin 0