Hi Lena, here is the recap of the CouchDB Meetup hamburg #3. I guess we could post it as an own blog post and then link to it in the weekly news. What do you think?
:) Thanks and Cheers Andy On 17 September 2014 22:30, Sebastian Rothbucher < [email protected]> wrote: > Hi, > > nehmt gern mein Recap unten wenn ihr mögt. > > Bis dahin! > Sebastian > > P.S.: ich werde das nächste Meetup vermutlich nicht schaffen > > > Recap Couch Meetup #3 > > > We gathered at UbiLabs again – on a Couch off course! > > > Robert started out presenting an interactive tutorial to help get > CouchDB started which will be on Github soon. It's no simulation – it's > getting hands dirty! And it's having a REAL Couch running and working at > the end of it. > > > While Robert started from the bottom, Meno approached Couch from the > High Performance Computing perspective. Although Couch can certainly not > compete with Hadoop, Cassandra and the likes in all aspects, there are good > take-aways for Couch-based implementations and Couch itself like: > > - > > Unit of Work: atomic updates are possible to one document (only). So > it is tempting to put a rather large graph (like a customer with all > invoices) into one document which off course keeps growing until it is no > more manageable. As it's not trivial to change this afterwards, one should > consider Unit of Work carefully when designing an application. > - > > Adding VS updating of documents is another aspect: the more > replication there is, the less likely it becomes to have no MVCC conflict. > This does not apply for adding. And looking at systems like Cassandra that > are very good in adding (with transactional integrity), there is yet > another architectural decision due. > - > > On the other hand, there is much room for improvement for retrieval of > data. Some systems go as far as calculating the physical actions of hard > disks, the higher speed within a rack (compared to outside of it), etc > - > > This becomes even more useful as data grows really massively (i.e. > there is massive sharding – a feature which will certainly also rock Couch > with the BigCouch merge). > - > > Likewise: materializing the index (like Couch does) is per se a good > thing to speed up retrieval (esp. as data keeps growing), but the effort to > index keeps increasing anyway. This effort also implies wait times between > a Map-Reduce job is written and a result is there. > - > > The growth can reach an extent where a Map-Reduce on all data becomes > impossible alltogether – hence the new idea of just reading data as it > comes in, drawing summaries and throwing the base data away immediately. > This could overcome the notion that Big Data has a scaling limit ;-) > - > > The single point of failure (which for instance Hadoop-setups can > have) is per se remedied with the Master-Master replication of Couch. > - > > The HTTP-based interface (while certainly being an advantage given the > usual driver-mess) could lead to applications difficult to port away as too > many assumption about the underlying database are made. Although there are > well-known examples of how to remedy this (like refactorings done for the > NPM repository), taking action too late might result in unpleasantly long > downtimes and high refactoring effort. > - > > When extending the HTTP communication with Couch and between Couches, > HTTP will already offer many possibilities for negotiating the maximum of > features both Couches understand. This can e.g. help in implementing resume > of downloads during replication. > - > > As it's safe to NOT assume networks trustworthy, SSL in Couch in place > is a plus > > > So, it was a great evening again. > > > > > 2014-09-17 17:05 GMT+02:00 Robert Kowalski <[email protected]>: > >> Hi Andy, >> >> ich fands ganz witzig gestern, war aber noch immer viel zu fertig von der >> JSConf.eu und nodeconf.eu - 8 Tage lang Konferenzmarathon. Meno war da, >> und wir haben über alternative Datenbanken wie Cassandra und auch Systeme >> wie Hadoop besprochen und was CouchDB fehlt. Cassandra fehlt leider auch >> ein paar Features mit den CouchDB auftrumpfen könnte: Managen der Racks die >> nodes enthalten im Rechenzentrum. Danach sprachen wir über Security: SSL, >> Verschlüsselung. Weiter gings dann mit möglichen Protokollimplementierungen >> für ein neues Replikationsprotokoll für CouchDB. >> >> Da ich gerade einen initialen CouchDB-Workshopper baue (Annoncement auf >> dev kommt bald) würde ich mich freuen wenn jemand anderes die >> Zusammenfassung macht. >> >> Den CouchDB-Day habe ich kurz angesprochen, Klaus und Sebastian denken >> auch dass es eine gute Idee ist. Ich kläre gerade mit Joan die Verwendung >> des Namen CouchDB / Apache CouchDB auf der Webseite zum Event. >> >> Viele Grüße, >> Robert >> >> Am 17. September 2014 11:20 schrieb Andy Wenk <[email protected]>: >> >> Hi Ihr, >>> >>> wie war's gestern? Hat jemand Lust Lena eine kurze Zusammenfassung von >>> gestern zu schicken? Und habt Ihr über den CouchDB Day gesprochen? >>> >>> Danke und Cheers >>> >>> Andy >>> >>> >>> 2014-09-16 8:55 GMT+02:00 Andy Wenk <[email protected]>: >>> >>>> Hallo Robert, >>>> >>>> extremely awesome! Und dann sollten wir noch Jan und Noah einladen und >>>> wenn er mag auch Dave. Super großartige Idee. >>>> >>>> Ich würde gerne schreiben, lass uns das heute Abend mal anquatschen >>>> aber leider hat sich ergeben, dass ich aus familiären Gründen heute Abend >>>> doch nicht dabei sein kann. Sorry dafür. Ev. habt Ihr ja Lust das schon mal >>>> anzusprechen und dann lass uns das sehr bald angehen. >>>> >>>> Ganz super geil! Das wird bestimmt cool. Danke Robert!!! >>>> >>>> Cheers >>>> >>>> Andy >>>> >>>> 2014-09-15 21:53 GMT+02:00 Robert Kowalski <[email protected]>: >>>> >>>>> Hallo zusammen, >>>>> >>>>> ich habe diese Idee von einem CouchDB-Day in Hamburg und würde gern >>>>> wissen was ihr davon denkt: >>>>> >>>>> Leute können vorbeikommen und mit uns an CouchDB arbeiten: das heißt >>>>> Code, Dokumentation, Translation, Artwork, Blogposts etc >>>>> >>>>> Und Neulinge können uns Fragen stellen, wie zum Beispiel das Apache >>>>> Projekt funktioniert oder wo welcher Code ist und wie man ihn am besten >>>>> ändert. >>>>> >>>>> Das ganze dann im Winter an einem Samstag von Mittags bis Abends. >>>>> >>>>> Bis morgen, >>>>> Robert >>>>> >>>> >>>> >>>> >>>> -- >>>> Andy Wenk >>>> Hamburg - Germany >>>> RockIt! >>>> >>>> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588 >>>> >>>> https://people.apache.org/keys/committer/andywenk.asc >>>> >>> >>> >>> >>> -- >>> Andy Wenk >>> Hamburg - Germany >>> RockIt! >>> >>> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588 >>> >>> https://people.apache.org/keys/committer/andywenk.asc >>> >> >> > -- Andy Wenk Hamburg - Germany RockIt! GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588 https://people.apache.org/keys/committer/andywenk.asc
