Mailing-List: contact marketing-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: marketing@couchdb.apache.org
MIME-Version: 1.0
Reply-To: andywenk@apache.org
In-Reply-To: <65F65883-3233-4777-A41A-5F45CE66D98C@thehoodiefirm.com>
References: 
 <CAJ1bcfHdJ2u_Q4stwJESVY+dLdkUHu2Yh5HAj-X-7LFwW1OrcQ@mail.gmail.com>
 <CADA9kr-W7bEPTJi7fz_Wm5o8XTwwQU7PuYp=AEDp977nbO3OYQ@mail.gmail.com>
 <CADA9kr9koERGhchoRRLch8vQWNaD8Lusni37t=k_GaMBRXz+ZA@mail.gmail.com>
 <CAJ1bcfESAcPEuGTsWJFSdkjweYE+3hr9T0w+Kn9nrnFR2=gkDA@mail.gmail.com>
 <CA+pq5focKfNkVLajXuZgAJsWeEH1KGDT-PaM7nGNrvPCuOMsAA@mail.gmail.com>
 <CADA9kr-YqdAgs-Qr8CNcJqxUgxmxAt8JZ5Dc_Y24Tp3Cq+oung@mail.gmail.com>
 <65F65883-3233-4777-A41A-5F45CE66D98C@thehoodiefirm.com>
From: Andy Wenk <andywenk@apache.org>
Date: Sat, 20 Sep 2014 11:03:31 +0200
Message-ID: 
 <CADA9kr_zGO_GCfkqMep9S=jXqY+4zWJnGg=oP9ucEwONpcjzsQ@mail.gmail.com>
Subject: Re: CouchDB Day
To: Lena Reinhard <lena@thehoodiefirm.com>,
	"marketing@couchdb.apache.org" <marketing@couchdb.apache.org>
Cc: Robert Kowalski <rok@kowalski.gd>,
 "sebastianro@apache.org" <sebastianro@apache.org>,
	Klaus Trainer <klaus_trainer@posteo.de>
Content-Type: multipart/alternative; boundary=089e0160bf98b0fa7f05037b7fd5

--089e0160bf98b0fa7f05037b7fd5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 <lena@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 i=
n
> 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 <andywenk@apache.org> wrote:
> >
> > Hi Lena,
> >
> > here is the recap of the CouchDB Meetup hamburg #3. I guess we could po=
st
> > 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=C3=B6gt.
> >>
> >> Bis dahin!
> >>    Sebastian
> >>
> >> P.S.: ich werde das n=C3=A4chste Meetup vermutlich nicht schaffen
> >>
> >>
> >> Recap Couch Meetup #3
> >>
> >>
> >> We gathered at UbiLabs again =E2=80=93 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 =E2=
=80=93 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 n=
ot
> >> 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 Cassandr=
a
> 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), e=
tc
> >>   -
> >>
> >>   This becomes even more useful as data grows really massively (i.e.
> >>   there is massive sharding =E2=80=93 a feature which will certainly a=
lso 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 become=
s
> >>   impossible alltogether =E2=80=93 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 t=
he
> >>   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 fo=
r
> 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 pla=
ce
> >>   is a plus
> >>
> >>
> >> So, it was a great evening again.
> >>
> >>
> >>
> >>
> >> 2014-09-17 17:05 GMT+02:00 Robert Kowalski <rok@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 =C3=BCber alternative Datenbanken wie Cassandra und auc=
h
> Systeme
> >>> wie Hadoop besprochen und was CouchDB fehlt. Cassandra fehlt leider
> auch
> >>> ein paar Features mit den CouchDB auftrumpfen k=C3=B6nnte: Managen de=
r
> Racks die
> >>> nodes enthalten im Rechenzentrum. Danach sprachen wir =C3=BCber Secur=
ity:
> SSL,
> >>> Verschl=C3=BCsselung. Weiter gings dann mit m=C3=B6glichen
> Protokollimplementierungen
> >>> f=C3=BCr ein neues Replikationsprotokoll f=C3=BCr CouchDB.
> >>>
> >>> Da ich gerade einen initialen CouchDB-Workshopper baue (Annoncement a=
uf
> >>> dev kommt bald) w=C3=BCrde ich mich freuen wenn jemand anderes die
> >>> Zusammenfassung macht.
> >>>
> >>> Den CouchDB-Day habe ich kurz angesprochen, Klaus und Sebastian denke=
n
> >>> auch dass es eine gute Idee ist. Ich kl=C3=A4re gerade mit Joan die
> Verwendung
> >>> des Namen CouchDB / Apache CouchDB auf der Webseite zum Event.
> >>>
> >>> Viele Gr=C3=BC=C3=9Fe,
> >>> Robert
> >>>
> >>> Am 17. September 2014 11:20 schrieb Andy Wenk <andywenk@apache.org>:
> >>>
> >>> Hi Ihr,
> >>>>
> >>>> wie war's gestern? Hat jemand Lust Lena eine kurze Zusammenfassung v=
on
> >>>> gestern zu schicken? Und habt Ihr =C3=BCber den CouchDB Day gesproch=
en?
> >>>>
> >>>> Danke und Cheers
> >>>>
> >>>> Andy
> >>>>
> >>>>
> >>>> 2014-09-16 8:55 GMT+02:00 Andy Wenk <andywenk@apache.org>:
> >>>>
> >>>>> Hallo Robert,
> >>>>>
> >>>>> extremely awesome! Und dann sollten wir noch Jan und Noah einladen
> und
> >>>>> wenn er mag auch Dave. Super gro=C3=9Fartige Idee.
> >>>>>
> >>>>> Ich w=C3=BCrde gerne schreiben, lass uns das heute Abend mal anquat=
schen
> >>>>> aber leider hat sich ergeben, dass ich aus famili=C3=A4ren Gr=C3=BC=
nden heute
> Abend
> >>>>> doch nicht dabei sein kann. Sorry daf=C3=BCr. 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 <rok@kowalski.gd>:
> >>>>>
> >>>>>> Hallo zusammen,
> >>>>>>
> >>>>>> ich habe diese Idee von einem CouchDB-Day in Hamburg und w=C3=BCrd=
e gern
> >>>>>> wissen was ihr davon denkt:
> >>>>>>
> >>>>>> Leute k=C3=B6nnen vorbeikommen und mit uns an CouchDB arbeiten: da=
s hei=C3=9Ft
> >>>>>> Code, Dokumentation, Translation, Artwork, Blogposts etc
> >>>>>>
> >>>>>> Und Neulinge k=C3=B6nnen uns Fragen stellen, wie zum Beispiel das =
Apache
> >>>>>> Projekt funktioniert oder wo welcher Code ist und wie man ihn am
> besten
> >>>>>> =C3=A4ndert.
> >>>>>>
> >>>>>> 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
>


--=20
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

--089e0160bf98b0fa7f05037b7fd5--