Hi , ok. Obviously the plan changed. As I was on a event with my company (and still am), I did not see your response. Sorry. I will prepare a blog post as soon as I have a time slot.
To the attendees - are there any photos form the event? Cheers Andy On 18 September 2014 09:45, Lena Reinhard <[email protected]> wrote: > Hi Andy, > > good idea! Definitely +1 from my side. > I'd then suggest we post this today and the News tomorrow (my computer > broke down and I'm having huge technical problems now which makes it > impossible to ship them today, but I can get the News ready by tomorrow in > any case). > If you want me to proofread the post, just let me know. Also, if one of > you got any photos from the meetup, maybe you'll want to add them as well. > > Best > Lena > > > On 17.09.2014, at 23:17, Andy Wenk <[email protected]> wrote: > > > > 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 > -- 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
