kranonit s06e01 Игорь Цинько: high load
TRANSCRIPT
High Load: If Chuck Norris is your customer
Igor [email protected]/in/IgorTsinko
goo.gl/7gidp#kranonit S06E01
23.12.2012
Igor Tsinko aka combats
● Java developer at ● In IT since 2003● 6 years PHP using, year of Java● linkedin.com/in/IgorTsinko
● Nur.kz (Connect.ua)● TomTom● VoxTelecom
Sergey Ponomarev aka stokito● Grails developer at ● In IT since 2006● Delphi, PHP, Java, Groovy● Java coucher● stokito.moikrug.ru● stokito.blogspot.com● HotWire.com
● Vertical vs. Horizontal scaling● Architecture● NoSQL vs. RDBMS● Tools
Agenda
What is high load?
Vertical vs. Horizontal scaling
● Horizontal scaling needs stateless● But: cookies, sessions are states● RESTful: only HTTP methods
Architecture
RESTful: CRUD over HTTP Create PUT example.com/articles/2
user: adminpass: qwertytitle: Hello, #kranonit!body: We create this article via REST
Read GET example.com/articles/1?user=admin&pass=qwerty
Update POST example.com/articles/2
user: adminpass: qwertytitle: Hello, #kranonit!body: Updated article text
Delete DELETE example.com/articles/2
user: adminpass: qwerty
Load Balancer
Zero downtime
● Different versions of app on different servers● Graceful error handling● Backward capability● Feature flags
CAP theorem: Consistency, Availability, Partition tolerance – choose two
ACID vs. BASE -> NoSQL
Only CRUD
● Create● Read● Update● Delete
Forget about complexity query ;(No aggregation requests (only Map/Reduce)
NoSQL boom! 122+ solutions
Polyglot persistence
MongoDB● Document oriented: schema less, easy to work with● ObjectId timestamp, machine identifier, process id, counter● JSON format:{"_id" : ObjectId("497ce96f395f2f052a494fd4"),"title" : "Awesome Blog Post","body" : "Text text text text, text text text ...","created": "Tue, 3 Jan 2011 11:13:56 GMT","tags" : [ "css", "javascipt", "jquery" ],"comments" : [ { "name" : "Kelly Glover" "text" : "This is a very good ..." }, ],}
Adding new NoSQL node is easy
Nodes are in ringThey know about each other
Recalculating keys/nodes
Runtime CAP-solvingQuorum read/write Fast writes
Fast reads Fast, less consistency
DEMO
Where could we use it?● Statistics● Messaging● Image metadata● and many others
Issues with NoSQL
● No standards● Very young infrastructure● Hard to configure
Spring DATA
● Single API● Pretty good ORM
● Doesn't support Cassandra● Issues with performance● The lowest common denominator
DEMO
How to test NoSQL
● Simple Integration tests (simple like in RDBMS)
● Storage - is a "bottleneck", but it testable● New tools are come to us: NoSQLUnit -
simple like DBUnit in RDBMS world● Good point for managers - just rewrite your
DAO
DEMO
Data retention policy
● What is your data lifecycle?● How many records in table?● How often it would be update?● Is it read only?● Data lifecycle: create, update, expire, clean● More reads or writes?● How often to clean old data?
"Cache" your DAO
● Static blocks on page● "slow-to update" data
Levels of caching:1. Object in DB session of application (ORM)2. In-memory shared with process: Memcached, EhCache3. Query caching: Sphinx, Hibernate
MemcachedSQL request for static data - is very expensiveCheap decision:
// get object from memcachedMemchached cities = get("cities_key")if (cities == null) { // make your SQL or whatever you do citiesList = query("SELECT * FROM cities") cities.set(citiesList, 60, "cities_key")}return cities
Memcached proc & cons
● Really quick access● Good for little pieces of data● Key-value
● Not so stable on real high load● You will loose your business if you reboot all
your memcache :)● 1mb objects by default
Memcache: how-to: team lead to beat shit out from you
● Cache transactional requests● Drop data from cache
Search on site: how-to kill your server, step-by-step manual ● SELECT * FROM ... CROSS JOIN ...● Aggregation requests● Wrong, or non-effective indexes
Move to Sphinx● Optimization by requests criteria● Full-text index● Optimisation and management your
requests
Other search engines and cache optimization tools
● Solr (Lucene) from Apache - Java world
● Google search on your site :)
Store your images - Varnish
It's just yet another http accelerator
● Store and shape your images● In-Memory based● Manage your files● It's not a hard drive (with 300 threads/s max)
Manage your video storages
● FFMpeg - best tool for conversion● Always save original file● User should understand that video doesn't
appear in seconds● Prepare your preview - use varnish
Bandwidth and video - or how-to save your ass from angry team lead● Don't use default configuration● Shape your bandwidth (include geotargeting)● Monetisation from your shaped bandwidth● MP4 shaping on little pieces
Storages architecture● Always use "rings"● Always protect your data - use 3 server per
ring with load balancer● App servers min value >= 2● Your SQL server - always with master-slave,
master-master replication● What is more important data for you - pics
with cats or commercial data?
When clouds are cool and when are not...
● Ping● Servers reliability● Private data
Why manager kick your ass for mongoDB in clouds
● MongoDB has master-node, in clouds you can't control servers reliability
● Every technology - is good decision for clouds... unless you don't care about 30's downtime
Technologies that uses our colleagues
● Google map-reduce● Google Big Data
Open source:● Hadoop● HBase
● ZooKeeper
Dependencies and limitations on the High Load architecture
● A lot of convention over configuration● Turn off your cache - turn off your business● You live in crashing world ● Much more qualified developer need
Conclusions● Use technologies only if it's business require● You're lucky if you have High Load● Persistence is bottleneck in any project: make
sure that you have good architecture - use DAO, decompose as more as you can
● Use SQL and vertical scale as much as possible
Что почитать?
● NoSQL DB - большой взрыв и расширяющаяся вселенная практических применений
● NoSQL базы данных: понимаем суть● Записи встреч Клуба анонимных разработчиков
#uadevclub● Кайл Бэнкер: MongoDB в действии● myforce.ru● insight-it.ru/highload● highload.ru
