Защо MongoDB?

Защо
?
Стефан Кънев
http://skanev.com/
@skanev
OpenFest
21 Ноември 2010
София
Monday, November 22, 2010

Аз съм Стефан,
приятно ми е.

програмист

http://skanev.com/

особен стил

говоря бързо

ръкомахам

“п.с.
това
момче
отдясно
рапър
ли
е
;)
?”
OpenFest 2009

много слайдове

нещо ново!

Мариян

Аз ползвам
Windows 7
OpenFest 2009

Аз ползвам
Visual Source Safe
P2P 2010

коварно: тази година той
говори последен

“Класически” Мариян

ала Salvador Dali

Friendly Mutton Chops

The Real Stuff

Имате въпроси?

1. Проблеми на релационните бази от данни
2. MongoDB отдалеч
3. Работа с MongoDB
4. Предимства и недостатъци
5. Някои приложения
6. MongoDB в живия живот

Disclaimer
Релационните бази работят, доказани са
и имат ред успешни приложения. Ако се
захващате с алтернативни сте в
експериментална територия и трябва да
сте готови да се оправяте сами.

Релационните
бази
са
сложни!DDL & DML
нормализация
индекси
inner/outer join
транзакции/изолация
6NF
денормализация

скубете си косата...
...или сте си оскубали косата

R MO

bject-to- elational apperR MO

клас таблица

не съвсем съвместими

ON DELETE CASCASE vs. callback в кода

несъвместимост между типовете
(например дати)

в кода vs. в базата

OOP RDBMS
ORM
В “думите” на господин Вен...
...само общата част от двата свята

лош програмен модел

Edgar Codd

Релационен
модел

теория

теория
≠
практика

на
теория:
Поставяте
данните
в
релации,
пишете
заявка
и
системата
автоматично
намира
как
да
я
изпълни
оптимално.

на
практика:
Уф,
‘що
не
ползва
тоя
иднекс?
Може
би
трябва
да

денормализирам
тази
таблица...


SQL
е
ужасен

Don Chamberlin
говори за SQL:

“Ray
and
I
thought
that
we
were

developing
a
language
that
would
be
used

mainly
by
‘casual
users’...”

“...we
were
trying
to
make
databases

accessible
to
a
new
class
of
users
who

were
not
trained
computer
scientists...”

“We
expected
to
see
SQL
used
directly
by

ﬁnancial
analysts,
urban
planners,
and

other
professionals
who
needed
access
to

data
but
did
not
want
to
write
computer

programs”

“In
fact,
over
the
years
a
great
deal
of
SQL

code
has
been
generated
by
automatic

tools,
a
development
that
was
not

foreseen
in
the
early
days.”

концептуални
проблеми

не
твърдя:
“Релационните
бази
са

неизползвамеви
за
повечето

приложения”

твърдя:
“Релационните
бази
са

скъпи
за
повечето

приложения”

NoSQL

Scientists have discovered
that 83% of all projects are better
of with MongoDB.True story.
Barney Stinson, Programmer

документно-‐ориентирана

scalability,
performances,
tons
of
features

OMG,
индекси!
(ако си мислите, че това не е проблем, пробвайте CouchDB)

производителност
функционалност
• memcached
• key/value
• RDBMS
• MongoDB
(според Mike Dirolf, един от авторите)

“MyISAM
on
meth”

бази
›
колекции
›
документи

колекции
≈
таблици

документите
са
JSON*
* с уговорки

{
"title": "Haskell rocks",
"text": "Today I played with...",
"tags": ["programming", "haskell"],
"author": {
"name": "Stefan Kanev",
"email": "stefan@example.org"
}
"views": 42
}
Блог пост

{
"body": "Today I played with...",
"notes": "Monads in Go?"
}
{
"title": "Io is awesome",
"tags": ['io', 'awesome'],
"notes": 5
}
Гъвкава схема
различни полета
различни типове

Типове
• нищо: null
• булева стойност: true, false
• 32bit/64bit цели числа: 42
• 64bit ﬂoat: 3.1415
• низове: “chunky bacon”
• дати: new Date()
• регулярен израз: /foobar/i
• код: function(x) { return x * x; }
• масиви: [2, 3, 5, 7, 11]
• обекти/документи: {foo: 1, bar: 2}

документите
всъщонст
са
BSON*
* бърз двоичен формат, MongoDB измислица

JavaScript
конзола

репликация

master-‐slave

replica
set

auto-‐sharding

{
"author": "skanev",
"views": 42
}
Примерен документ

> db.posts.insert({
"author": "skanev",
"views": 42
})
Добавяне
глобална променлива в конзолата за текущата база
име на колекцията
команда

> db.posts.find()
{
"_id" : ObjectId("4ce653278f4f936035707875"),
"title" : "Haskell rocks",
"author" : "skanev",
"text" : "Today I played with...",
"tags" : [
"programming",
"haskell"
],
"views" : 42
}
...и резултатът

_id
• специален ключ,
• всеки документ го има
• уникален е в рамките на колекция
• какъвто и да е тип

> db.posts.update({title: "Haskell rocks"}, {
title: "Haskell is cool",
author: "skanev",
body: "Today I played with..."
})
Обновяване на документ

> db.posts.findOne()
{
"_id" : ObjectId("4ce653278f4f936035707875"),
"title" : "Haskell is cool",
"author" : "skanev",
"body" : "Today I played with..."
}
След записа
tags и views ги няма

> db.posts.update({_id:"4ce653278f4f936035707875"},{
title: "Haskell is cool",
author: "skanev",
body: "Today I played with..."
})
Обикновено ползвате _id

db.posts.update(
{'title': 'Haskell rocks'},
{'$set': {'title': 'Haskell is weird'}}
)
Промяна на единично поле

Модификатори ($set)
• Не са имена на полета
• Значат нещо специално за Mongo
• Започват с $
• Preﬁx-а може да се промени при клиента

инкрементиране на брояч

var views = db.posts.
findOne({title: "Haskell rocks"}).views
db.posts.update(
{'$set': {'views': views + 1}}
)
Може така...
...но има проблеми

...но по-добрият вариант е
db.posts.update(
{'$inc': {'views': 1}}
)

работа с масиви

{
"tags": ["weird", "haskell"],
}
Документ

Добавяне на таг
db.posts.update(
{'$push': {'tags': 'fun'}}
)
> db.posts.findOne()
{
"_id" : ObjectId("4ce7acf86fe4256367d98353"),
"tags" : ["weird", "haskell", "fun"],
"title" : "Haskell rocks"
}

Или пък
db.posts.update(
{'$addToSet': {'tags': 'weird'}}
)

вложени документи

{
"author": {
"name": "Stefan Kanev",
"email": "stefan.kanev@example.org"
}
}
Документът...

...и промяната
db.posts.update(
{"author.name": "Stefan Kanev"},
{"$set": {"author.email": "skanev@example.com"}}
)

заявки за търсене

db.posts.find({"author": "skanev"})
Съвпадение по поле

Само определени полета
db.posts.find(
{"author": "skanev"},
{"title": 1, "tags": 1}
)

Сравнения
db.posts.find({"views": {"$gt": 1000}})
db.posts.find({"views": {"$gt": 1000, "$lt": 2000}})

$in
db.posts.find({
"author": {"$in": ['skanev', 'stefan', 'kanev']}
})

Дизюнкция
(или на прост български: OR)
db.posts.find({
"$or": [
{"author": "skanev"},
{"views": {"$gte": 1000}}
]
})

Търсене в масиви
db.posts.find({"tags": "haskell"})
db.posts.find({
"tags": {"$all": ["programming", "haskell"]}
})
db.posts.find({"tags": {"$size": 2}})

Вложени документи
db.people.find({
"name.first": "Stefan",
"name.last": "Kanev"
})

има и още...
$gt $lt $gte $lte $ne
$all $in $nin $not $mod
$size $exists $type $elemMatch

$where
db.people.find({
"$where": function() {
return this.age % 2 == 0;
}
})

MapReduce

GridFS

server-‐side
javascript

Corey Haines

#positivember

Хубавото в MongoDB

бързо

horizontal
scalability

feature-‐rich

Лошото в MongoDB

администрация
;(

memory
mapped-‐ﬁles

особености
при
back-‐up

no
single-‐server
durability

много
инстанции
на
mongo

сега
е
#positivember,
а
всичко
това
е
много
негативно;
затова
мислете
така:

улеснява
програмирането
за

сметка
на
системната

администрация

балансира
сложността
между

програмистите
и
админите

намира
работа
на
админите

кара
администраторите
да
се

чустват
полезни

мизантропи и
социопати
пълноценни
членове на
обществото
Системни администратори
принос,
самочувствие

MongoDB
е
полезно
за

админите

...но
сериозно...

три проблема, които не са
директно с производителност

MyISAM
120
000
000
записа
200
GB
таблица

...искам
да
добавя
нова
колона

ALTER TABLE articles
около
20
часа

спъва
развитието
на
продукта
прави
deploy-‐а
ръчен
никой
не
иска
да
смъкне
сайта

без заключване на таблици

1. променяме кода да работи с двата
варианта
2. времеемка миграция, която не заключва
нищо
3. премахваме поддръжката за стария
вариант
Рецепта

импортираме
от
legacy
база...
...от
таблица
с
188
колони

orgnr skatter_AB soliditet_AB sumomstillg_KONC roresfdisp_KONC antalanst_KONC_X
lan aretsres_AB kaslikv_AB sparrkonto_KONC omsattfor_KONC oms_KONC_X
kommun likvmed_AB kasflfror_AB maskoinv_KONC forsumtillg_KONC resfbok_KONC_X
bolform kundford_AB avkegkap_AB sumanltillg_KONC regdatum_AB aretsres_KONC_X
ftgnamn varulager_AB avktotkap_AB sumtillg_KONC styrelse_AB sumtillg_KONC_X
copers ovromstillg_AB lonekanst_AB levskuld_KONC histnamn_AB aktiekap_KONC_X
utdadress sumomstillg_AB roresfdisp_AB sumkortfsk_KONC firmteck_AB sumegkap_KONC_X
postnr sparrkonto_AB omsattfor_AB sumlangfsk_KONC bolord_AB netrespoms_KONC_X
postort maskoinv_AB forsumtillg_AB obesres_KONC regdatum_HB vinstmarg_KONC_X
riktnr sumanltillg_AB bokslut_start_KONC aktiekap_KONC styrelse_HB omsanst_KONC_X
abbnr sumtillg_AB bokslut_slut_KONC ovrbundkap_KONC histnamn_HB soliditet_KONC_X
verkstat levskuld_AB aktieutd_KONC obunegkap_KONC firmteck_HB kaslikv_KONC_X
aktivstat sumkortfsk_AB antalanst_KONC sumegkap_KONC bolord_HB avktotkap_KONC_X
sni sumlangfsk_AB lonoers_KONC sumskegkap_KONC status_konk_HB lonekanst_KONC_X
dkm_AB obesres_AB oms_KONC goodwill_KONC status_likv_HB omsattfor_KONC_X
bokslut_start_AB aktiekap_AB resfavskr_KONC panter_KONC sekv_HB bolstatus
bokslut_slut_AB ovrbundkap_AB avskr_KONC ansvar_KONC antalanst_AB_X styrelse_X
aktieutd_AB obunegkap_AB reseavskr_KONC fastigheter_KONC oms_AB_X fbokstav
antalanst_AB sumegkap_AB finint_KONC revanm_KONC resfbok_AB_X bolord_X
lonoers_AB sumskegkap_AB finkostn_KONC ntstart_KONC aretsres_AB_X histnamn_X
oms_AB goodwill_AB resefin_KONC ntslut_KONC sumtillg_AB_X regdatum_X
resfavskr_AB panter_AB extordint_KONC resfavspoms_KONC aktiekap_AB_X koncern_X
avskr_AB ansvar_AB extordkost_KONC netrespoms_KONC sumegkap_AB_X publikt_X
reseavskr_AB fastigheter_AB resfbok_KONC vinstmarg_KONC netrespoms_AB_X kommun_X
finint_AB revanm_AB boksldisp_KONC omsanst_KONC vinstmarg_AB_X senaste_AB
finkostn_AB ntstart_AB skatter_KONC soliditet_KONC omsanst_AB_X senaste_KONC
resefin_AB ntslut_AB aretsres_KONC kaslikv_KONC soliditet_AB_X skod
extordint_AB resfavspoms_AB likvmed_KONC kasflfror_KONC kaslikv_AB_X tkod
extordkost_AB netrespoms_AB kundford_KONC avkegkap_KONC avktotkap_AB_X datum
resfbok_AB vinstmarg_AB varulager_KONC avktotkap_KONC lonekanst_AB_X forgnr
boksldisp_AB omsanst_AB ovromstillg_KONC lonekanst_KONC omsattfor_AB_X antal_cfar
antal_ort ort
188 колони

1 таблица, 1 ред
⇓
7 таблици, 30 реда

1.
показваме
на
една
страница
2.
даваме
на
SOLR
за
иднексация

7 класа + 7 таблици = bloat

по-‐просто
по-‐бързо

клиент
с
кофти
изисквания

“Ще
правим
магазин.
Искам
да

мога
да
добавям
нови
типове

продукти
и
да
променям

атрибутите
на
съществуващите,

както
и
да
има
търсене
по
тях”

entity-‐attribute-‐value
id key value
1 name hoodie
1 color blue
2 name shirt

трудни
заявки
губите
типове
няма
индекси
бавно

сериализиран
обект
json,
yaml,
pickle

никакви
заявки
никакви
индекси
външен
софтуер

Въпроси

Защо MongoDB?

Recomendados

Recomendados

Mais conteúdo relacionado

Mais de Stefan Kanev

Mais de Stefan Kanev (18)

Защо MongoDB?