You are viewing a plain text version of this content. The canonical link for it is here.
Posted to marketing@couchdb.apache.org by Andy Wenk <an...@apache.org> on 2014/09/17 23:17:37 UTC
Re: CouchDB Day
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 <
sebastianrothbucher@googlemail.com> 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 <ro...@kowalski.gd>:
>
>> 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 <an...@apache.org>:
>>
>> 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 <an...@apache.org>:
>>>
>>>> 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 <ro...@kowalski.gd>:
>>>>
>>>>> 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
Re: CouchDB Day
Posted by Noah Slater <ns...@apache.org>.
This is a great idea. +1 to a blog post and then a mention in the weekly news!
On 20 September 2014 11:03, Andy Wenk <an...@apache.org> wrote:
> 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 <le...@thehoodiefirm.com> 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 <an...@apache.org> 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 <
>> > sebastianrothbucher@googlemail.com> 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 <ro...@kowalski.gd>:
>> >>
>> >>> 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 <an...@apache.org>:
>> >>>
>> >>> 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 <an...@apache.org>:
>> >>>>
>> >>>>> 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 <ro...@kowalski.gd>:
>> >>>>>
>> >>>>>> 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
--
Noah Slater
https://twitter.com/nslater
Re: CouchDB Day
Posted by Andy Wenk <an...@apache.org>.
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 <le...@thehoodiefirm.com> 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 <an...@apache.org> 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 <
> > sebastianrothbucher@googlemail.com> 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 <ro...@kowalski.gd>:
> >>
> >>> 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 <an...@apache.org>:
> >>>
> >>> 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 <an...@apache.org>:
> >>>>
> >>>>> 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 <ro...@kowalski.gd>:
> >>>>>
> >>>>>> 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
Re: CouchDB Day
Posted by Lena Reinhard <le...@thehoodiefirm.com>.
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 <an...@apache.org> 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 <
> sebastianrothbucher@googlemail.com> 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 <ro...@kowalski.gd>:
>>
>>> 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 <an...@apache.org>:
>>>
>>> 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 <an...@apache.org>:
>>>>
>>>>> 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 <ro...@kowalski.gd>:
>>>>>
>>>>>> 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