Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 0E887200B98 for ; Mon, 3 Oct 2016 18:37:30 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 0D371160ADC; Mon, 3 Oct 2016 16:37:30 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id D2555160ACD for ; Mon, 3 Oct 2016 18:37:26 +0200 (CEST) Received: (qmail 68028 invoked by uid 500); 3 Oct 2016 16:37:25 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 68018 invoked by uid 99); 3 Oct 2016 16:37:25 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Oct 2016 16:37:25 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 7E7EB180290 for ; Mon, 3 Oct 2016 16:37:24 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.48 X-Spam-Level: ** X-Spam-Status: No, score=2.48 tagged_above=-999 required=6.31 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=2, KAM_LINEPADDING=1.2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Received: from mx2-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id AnOeFZqs8C2I for ; Mon, 3 Oct 2016 16:37:20 +0000 (UTC) Received: from mail-ua0-f170.google.com (mail-ua0-f170.google.com [209.85.217.170]) by mx2-lw-us.apache.org (ASF Mail Server at mx2-lw-us.apache.org) with ESMTPS id 449BE5F4EC for ; Mon, 3 Oct 2016 16:37:20 +0000 (UTC) Received: by mail-ua0-f170.google.com with SMTP id n13so155204564uaa.3 for ; Mon, 03 Oct 2016 09:37:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=yvs2BmUbkxnorIw0OjIDyQVIXZKNFFMmFXVNtaVQTFI=; b=eV+Bib/wD707JRzywH6YtXuU7eT1Kab3EOi+XISwLQpKwuSveNMqUBYdnxo3AG/EKi MZg+uqm8eNXMnwdN6dwjaLJT3ynv6eTH2EZEsca+xBciNC/MSJaMWk8HVFrgH9XyHllm pqniVPkc7AcPwKOg/JBnWHcd3HV3fUwx6IhuHJUmIDvMGoMuucpPUfKwaXkDHcLjznb8 qmBmxmaEFyYrOvHNB4m5ZGRMnDROel/QHXD4669PPRonXM3cl4M/xgXFwK7yEm73VLT2 /wmzLKCSXQXl4XkXIJIP8WQdRhh4gUl3S6GGnIHsNh4gE54eUMeaWoWaON5I6jca3oEN sBlQ== X-Gm-Message-State: AA6/9RlTv9CL9OUYKDEfEDsYh4jEm6weqV4TwJeQOi6B/aHA81LEisQEg2bU3G9pQUBt36sGtj5yOWDYDaxdnA== X-Received: by 10.176.69.141 with SMTP id u13mr11060011uau.176.1475512639629; Mon, 03 Oct 2016 09:37:19 -0700 (PDT) MIME-Version: 1.0 References: <2045743758.13821426.1475252660560.JavaMail.zimbra@dbi-services.com> In-Reply-To: From: Jonathan Haddad Date: Mon, 03 Oct 2016 16:37:08 +0000 Message-ID: Subject: Re: Cassandra data model right definition To: "user@cassandra.apache.org" Content-Type: multipart/related; boundary=94eb2c0cbf7abf4847053df88e46 archived-at: Mon, 03 Oct 2016 16:37:30 -0000 --94eb2c0cbf7abf4847053df88e46 Content-Type: multipart/alternative; boundary=94eb2c0cbf7abf4845053df88e45 --94eb2c0cbf7abf4845053df88e45 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's a row store because its schemed (vs ad hoc documents), and data (rows) are stored together. What would you call the things you iterate over when you query a partition? Rows. That makes it a thing that stores "rows" of data, row store isn't some crazy stretch. On Mon, Oct 3, 2016 at 12:33 PM Jonathan Haddad wrote: > Nobody is claiming Cassandra is a relational I'm not sure why that keeps > coming up. > On Mon, Oct 3, 2016 at 10:53 AM Edward Capriolo > wrote: > > My original point can be summed up as: > > Do not define cassandra in terms SMILES & METAPHORS. Such words include > "like" and "close relative". > > For the specifics: > > > Any relational db could (and I'm sure one does!) allow for sparse fields > as well. MySQL can be backed by rocksdb now, does that make it not a row > store? > > > Lets draw some lines, a relational database is clearly defined. > > https://en.wikipedia.org/wiki/Edgar_F._Codd > > Codd's theorem , a result > proven in his seminal work on the relational model, equates the expressiv= e > power of relational algebra > and relational calculu= s > (both of which, > lacking recursion, are strictly less powerful thanfirst-order logic > ).[*citation needed > *] > > As the relational model started to become fashionable in the early 1980s, > Codd fought a sometimes bitter campaign to prevent the term being misused > by database vendors who had merely added a relational veneer to older > technology. As part of this campaign, he published his 12 rules > to define what > constituted a relational database. This made his position in IBM > increasingly difficult, so he left to form his own consulting company wit= h > Chris Date and others. > > Cassandra is not a relational database. > > I am have attempted to illustrate that a "row store" is defined as well. = I > do not believe Cassandra is a "row store". > > > > "Just because it uses log structured storage, sparse fields, and > semi-flexible collections doesn't disqualify it from calling it a "row > store"" > > What is the definition of "row store". Is it a logical construct or a > physical one? > > Why isn't mongo DB a "row store"? I can drop a schema on top of mongo and > present it as rows and columns. It seems to pass the litmus test being > presented. > > https://github.com/mongodb/mongo-hadoop/wiki/Hive-Usage > > > > > > On Mon, Oct 3, 2016 at 10:02 AM, Jonathan Haddad > wrote: > > Sorry Ed, but you're really stretching here. A table in Cassandra is > structured by a schema with the data for each row stored together in each > data file. Just because it uses log structured storage, sparse fields, an= d > semi-flexible collections doesn't disqualify it from calling it a "row > store" > > Postgres added flexible storage through hstore, I don't hear anyone > arguing that it needs to be renamed. > > Any relational db could (and I'm sure one does!) allow for sparse fields > as well. MySQL can be backed by rocksdb now, does that make it not a row > store? > > You're arguing that everything is wrong but you're not proposing an > alternative, which is not productive. > On Mon, Oct 3, 2016 at 9:40 AM Edward Capriolo > wrote: > > Also every piece of techincal information that describes a rowstore > > http://cs-www.cs.yale.edu/homes/dna/talks/abadi-sigmod08-slides.pdf > https://en.wikipedia.org/wiki/Column-oriented_DBMS#Row-oriented_systems > > Does it like this: > > 001:10,Smith,Joe,40000; > 002:12,Jones,Mary,50000; > 003:11,Johnson,Cathy,44000; > 004:22,Jones,Bob,55000; > > > > The never depict a scenario where a the data looks like this on disk: > > 001:10,Smith > > 001:10,40000; > > Which is much closer to how Cassandra *stores* it's data. > > > > On Fri, Sep 30, 2016 at 5:12 PM, Benedict Elliott Smith < > benedict@apache.org> wrote: > > Absolutely. A "partitioned row store" is exactly what I would call it. > As it happens, our README thinks the same, which is fantastic. > > I thought I'd take a look at the rest of our cohort, and didn't get far > before disappointment. HBase literally calls itself a "*column-oriented*= store" > - which is so totally wrong it's simultaneously hilarious and tragic. > > I guess we can't blame the wider internet for misunderstanding/misnaming > us poor "wide column stores" if even one of the major examples doesn't kn= ow > what it, itself, is! > > > > > On 30 September 2016 at 21:47, Jonathan Haddad wrote: > > +1000 to what Benedict says. I usually call it a "partitioned row store" > which usually needs some extra explanation but is more accurate than > "column family" or whatever other thrift era terminology people still use= . > On Fri, Sep 30, 2016 at 1:53 PM DuyHai Doan wrote: > > I used to present Cassandra as a NoSQL datastore with "distributed" table= . > This definition is closer to CQL and has some academic background > (distributed hash table). > > > On Fri, Sep 30, 2016 at 7:43 PM, Benedict Elliott Smith < > benedict@apache.org> wrote: > > Cassandra is not a "wide column store" anymore. It has a schema. Only > thrift users no longer think they have a schema (though they do), and > thrift is being deprecated. > > I really wish everyone would kill the term "wide column store" with fire. > It seems to have never meant anything beyond "schema-less, row-oriented", > and a "column store" means literally the opposite of this. > > Not only that, but people don't even seem to realise the term "column > store" existed long before "wide column store" and the latter is often > abbreviated to the former, as here: > http://www.planetcassandra.org/what-is-nosql/ > > Since it no longer applies, let's all agree as a community to forget this > awful nomenclature ever existed. > > > > On 30 September 2016 at 18:09, Joaquin Casares > wrote: > > Hi Mehdi, > > I can help clarify a few things. > > As Carlos said, Cassandra is a Wide Column Store. Theoretically a row can > have 2 billion columns, but in practice it shouldn't have more than 100 > million columns. > > Cassandra partitions data to certain nodes based on the partition key(s), > but does provide the option of setting zero or more clustering keys. > Together, the partition key(s) and clustering key(s) form the primary key= . > > When writing to Cassandra, you will need to provide the full primary key, > however, when reading from Cassandra, you only need to provide the full > partition key. > > When you only provide the partition key for a read operation, you're able > to return all columns that exist on that partition with low latency. Thes= e > columns are displayed as "CQL rows" to make it easier to reason about. > > Consider the schema: > > CREATE TABLE foo ( > bar uuid, > > boz uuid, > > baz timeuuid, > data1 text, > > data2 text, > > PRIMARY KEY ((bar, boz), baz) > > ); > > > When you write to Cassandra you will need to send bar, boz, and baz and > optionally data*, if it's relevant for that CQL row. If you chose not to > define a data* field for a particular CQL row, then nothing is stored nor > allocated on disk. But I wouldn't consider that caveat to be "schema-less= ". > > However, all writes to the same bar/boz will end up on the same Cassandra > replica set (a configurable number of nodes) and be stored on the same > place(s) on disk within the SSTable(s). And on disk, each field that's no= t > a partition key is stored as a column, including clustering keys (this is > optimized in Cassandra 3+, but now we're getting deep into internals). > > In this way you can get fast responses for all activity for bar/boz eithe= r > over time, or for a specific time, with roughly the same number of disk > seeks, with varying lengths on the disk scans. > > Hope that helps! > > Joaquin Casares > Consultant > Austin, TX > > Apache Cassandra Consulting > http://www.thelastpickle.com > > On Fri, Sep 30, 2016 at 11:40 AM, Carlos Alonso > wrote: > > Cassandra is a Wide Column Store http://db-engines.com/en/system/Cassandr= a > > Carlos Alonso | Software Engineer | @calonso > > On 30 September 2016 at 18:24, Mehdi Bada > wrote: > > Hi all, > > I have a theoritical question: > - Is Apache Cassandra really a column store? > Column store mean storing the data as column rather than as a rows. > > In fact C* store the data as row, and data is partionned with row key. > > Finally, for me, Cassandra is a row oriented schema less DBMS.... Is it > true for you also??? > > Many thanks in advance for your reply > > Best Regards > Mehdi Bada > ---- > > *Mehdi Bada* | Consultant > Phone: +41 32 422 96 00 | Mobile: +41 79 928 75 48 | Fax: +41 32 422 96 1= 5 > dbi services, Rue de la Jeunesse 2, CH-2800 Del=C3=A9mont > mehdi.bada@dbi-services.com > www.dbi-services.com > > > > > *=E2=87=92 dbi services is recruiting Oracle & SQL Server experts ! =E2= =80=93 Join the > team > * > > > > > > > > --94eb2c0cbf7abf4845053df88e45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's a row store because its schemed (vs ad hoc documents), and data (r= ows) are stored together. What would you call the things you iterate over w= hen you query a partition? Rows. That makes it a thing that stores "ro= ws" of data, row store isn't some crazy stretch.
On Mon, Oct 3, 2016 at 12:33 PM Jonathan Had= dad <jon@jonhaddad.com> wrot= e:
Nobody is claiming Cassandra is = a relational I'm not sure why that keeps coming up.
On Mon, Oct 3, 2016 at 10:53 AM Edward Capriolo <edlinuxguru@gma= il.com> wrote:
My original point can= be summed up as:

Do not def= ine cassandra in terms SMILES & METAPHORS. Such words include "lik= e" and "close relative".=C2=A0

For the specifics:


Any relational db could (and I'm= sure one does!) allow for sparse fields as well. MySQL can be backed by ro= cksdb now, does that make it not a row store?


Lets draw some lines, a relational database is clearly defin= ed.

https://en.wiki= pedia.org/wiki/Edgar_F._Codd

Codd's theorem, a result proven in his= seminal work on the relational model, equates the expressive power of=C2= =A0relational algebra= =C2=A0and=C2=A0= relational calculus=C2=A0(both of which, lacking recursion, are strictl= y less powerful thanfir= st-order logic).[= citation needed]=

As the relational model s= tarted to become fashionable in the early 1980s, Codd fought a sometimes bi= tter campaign to prevent the term being misused by database vendors who had= merely added a relational veneer to older technology. As part of this camp= aign, he published his=C2=A012 rules=C2=A0to define what constituted a relational databa= se. This made his position in IBM increasingly difficult, so he left to for= m his own consulting company with Chris Date and others.

Cassandra is not a relational da= tabase.

I am have attempted to illustrate that a = "row store" is defined as well. I do not believe Cassandra is a &= quot;row store".=C2=A0



"Just because it uses log s= tructured storage, sparse fields, and semi-flexible collections doesn't= disqualify it from calling it a "row store""

What is the definition of "row store". Is it a = logical construct or a physical one?

Why isn't mongo DB a "row store"? I can drop a sche= ma on top of mongo and present it as rows and columns. It seems to pass the= litmus test being presented.

https://github.com/mongodb/mongo-hadoop/wi= ki/Hive-Usage





On Mon, Oct 3, 2016= at 10:02 AM, Jonathan Haddad <jon= @jonhaddad.com> wrote:
Sorry Ed, but you're really stretc= hing here. A table in Cassandra is structured by a schema with the data for= each row stored together in each data file. Just because it uses log struc= tured storage, sparse fields, and semi-flexible collections doesn't dis= qualify it from calling it a "row store"
<= br class=3D"gmail_msg">Postgres added flexible storage through hstore, I do= n't hear anyone arguing that it needs to be renamed.

Any relational db could (and I'm sure one= does!) allow for sparse fields as well. MySQL can be backed by rocksdb now= , does that make it not a row store?

You're arguing that everything is wrong but you're not pro= posing an alternative, which is not productive.
On Mo= n, Oct 3, 2016 at 9:40 AM Edward Capriolo <edlinuxguru@gmail.com= > wrote:
Also every piece of techincal in= formation that describes a rowstore

http://cs-www.cs.yale.edu/h= omes/dna/talks/abadi-sigmod08-slides.pdf
https://en.wikipedia.org/wiki/Column= -oriented_DBMS#Row-oriented_systems

Does it like this:=C2=A0
001:10,Smith,Joe,40000;
002:12,Jones,Mary,50000;
003:11,Johnson,Cathy,44000;
004:22,Jones,Bob,55000;


= The never depict a scenario where a the data looks like this on disk:

001:10,Smith
001:10,40000;
Which is much clos= er to how Cassandra stores it's data.



On Fri, Sep 30, 2016 at 5:12 PM, Benedict Elliott Smith <benedict@apache.org> wrote= :
Absolutely.=C2=A0 A "partitioned row store&qu= ot; is exactly what I would call it.=C2=A0 As it happens, our README thinks= the same, which is fantastic. =C2=A0

I thought I'd take a look at the= rest of our cohort, and didn't get far before disappointment.=C2=A0 HB= ase literally calls itself a "column-oriented=C2=A0store" - which is so totally wrong it's simultaneously hila= rious and tragic. =C2=A0

I guess we can't blame the wider internet for= misunderstanding/misnaming us poor "wide column stores" if even = one of the major examples doesn't know what it, itself, is!



On 30 Sept= ember 2016 at 21:47, Jonathan Haddad &= lt;jon@jonhaddad.com> wrote:
+1000 to what Benedict says. I usually call it= a "partitioned row store" which usually needs some extra explana= tion but is more accurate than "column family" or whatever other = thrift era terminology people still use.
On Fri, Sep 30, 2016 at 1:53 PM DuyHai Do= an <doanduyhai@gmail.com> wrote:
I= used to present Cassandra as a NoSQL datastore with "distributed"= ; table. This definition is closer to CQL and has some academic background = (distributed hash table).


On Fri, Sep 30, 2016 at 7:43 PM, Benedict Elli= ott Smith <benedict@apache.org= > wrote:
Cassandra is not a "wide column store" anymore.=C2= =A0 It has a schema.=C2=A0 Only thrift users no longer think they have a sc= hema (though they do), and thrift is being deprecated.

I really wish everyone would kill the term "wide colum= n store" with fire.=C2=A0 It seems to have never meant anything beyond= "schema-less, row-oriented", and a "column store" mean= s literally the opposite of this.

Not only th= at, but people don't even seem to realise the term "column store&q= uot; existed long before "wide column store" and the latter is of= ten abbreviated to the former, as here: http://www.plan= etcassandra.org/what-is-nosql/=C2=A0

Since it no longer applies,= let's all agree as a community to forget this awful nomenclature ever = existed.


=

On 30 September 2016 at 18:09, = Joaquin Casares <joaquin@the= lastpickle.com> wrote:
Hi Mehdi,

I ca= n help clarify a few things.

As Carlos said, Cassandra is a Wide Col= umn Store. Theoretically a row can have 2 billion columns, but in practice = it shouldn't have more than 100 million columns.

Cassandra parti= tions data to certain nodes based on the partition key(s), but does provide= the option of setting zero or more clustering keys. Together, the=C2=A0par= tition=C2=A0key(s) and clustering key(s) form the primary key.

When = writing to Cassandra, you will need to provide the full primary key, howeve= r, when reading from Cassandra, you only need to provide the full partition= key.

When you only provide the partition key for a read operation,= you're able to return all columns that exist on that partition with lo= w latency. These columns are displayed as "CQL rows" to make it e= asier to reason about.

=
Consider the schema:

CRE= ATE TABLE foo (
=C2=A0 bar uuid,
=C2=A0 boz uuid,
=C2=A0 baz timeuuid,
=C2=A0 data1 text,
=C2=A0 data2 text,
=C2=A0 PRIMARY KEY ((bar, boz), baz)
);

When you write to Cassandra you will need to sen= d bar, boz, and baz and optionally data*, if it's relevant for that CQL= row. If you chose not to define a data* field for a particular CQL row, th= en nothing is stored nor allocated on disk. But I wouldn't consider tha= t caveat to be "schema-less".

However, all writes to the s= ame bar/boz will end up on the same Cassandra replica set (a configurable n= umber of nodes) and be stored on the same place(s) on disk within the SSTab= le(s). And on disk, each field that's not a partition key is stored as = a column, including clustering keys (this is optimized in Cassandra 3+, but= now we're getting deep into internals).
<= br class=3D"m_3152848913174576764m_-940935237497870652m_-182609832746578886= 4gmail_msg gmail_msg">
In this way you can get= fast responses for all activity for bar/boz either over time, or for a spe= cific time, with roughly the same number of disk seeks, with varying length= s on the disk scans.

Hope that helps!

Joaquin Casares
Consultant
Austi= n, TX

Apache Cassandra Consulting
h= ttp://www.thelastpickle.com

On Fri, Sep 30, = 2016 at 11:40 AM, Carlos Alonso <in= fo@mrcalonso.com> wrote:
Cassandra is = a Wide Column Store=C2=A0http://db-engines.com/en/system/Ca= ssandra

Carlos Alonso | Software Engineer = |=C2=A0@calonso

On 30 September = 2016 at 18:24, Mehdi Bada <mehdi.bada@dbi-services.com> wrote:
<= blockquote class=3D"gmail_quote m_3152848913174576764m_-940935237497870652m= _-1826098327465788864gmail_msg gmail_msg" style=3D"margin:0 0 0 .8ex;border= -left:1px #ccc solid;padding-left:1ex">
Hi all,

I have a theoritical question:
- Is Apache Cassandra really a column store?
Column store mean storing the data as c= olumn rather than as a rows.

In fact C* stor= e the data as row, and data is partionned with row key.

Finally, for me, Cassandra is a row oriented schema less DBMS...= . Is it true for you also???

Many thanks in a= dvance for your reply
<= br class=3D"m_3152848913174576764m_-940935237497870652m_-182609832746578886= 4gmail_msg gmail_msg">
Best Regards
Mehdi Bada
----

Mehdi Bada | Consultant
Phone: +41 32 422 96 00 | Mobile: +41 79 9= 28 75 48 | Fax:=C2=A0<= span style=3D"font-family:arial,helvetica,sans-serif;color:#808080;font-siz= e:8pt" class=3D"m_3152848913174576764m_-940935237497870652m_-18260983274657= 88864gmail_msg gmail_msg">+41 32 422 96 15=
dbi services, Rue de la Jeunesse 2,= CH-2800 Del=C3=A9mont
mehdi.bada@dbi-services.co= m



=E2=87=92 dbi services is recruiting Oracle & SQL Server= experts ! =E2=80=93 Join the team
<= /div>





--94eb2c0cbf7abf4845053df88e45-- --94eb2c0cbf7abf4847053df88e46 Content-Type: image/png; name="logo signature.png" Content-Disposition: inline; filename="logo signature.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: db6081752cd6482e_0.1.1 iVBORw0KGgoAAAANSUhEUgAAAXUAAAAnCAIAAAB/rk/XAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAA6pSURBVHhe7Z1pUFvXFcdfO0mbdPqhM51m2mZt J9tMJh/6oUmnbToTO15xnMXjJplJtyzTOHXjJI0TGxvjQHBiiBOCzWLA2MYLYjE2ZhU2GBsj9n0n FhL7asxiBJJA9C+dx/Xzk54kZEiUzP3NG807955777nb/90nwBbmOBwOZ2ng+sLhcJaKm/RldHS0 u7tbq9W2cxaCXq8fGhoym83iOHI4HBuivlgsloGBgf7+foPBMD09beS4DYZramoK0tzV1WUymWg8 ORwOEPVlYmKir6+Pbw+PgUCPjY319vaKNofDYfqC1yI8hOme4xlQZ51OJxocDofpi1ar5fpy63R2 dop3HA6H6Ut7e7tX68us2Xp5PVxfOBwpi6kvNbrhFf5ZT+/IrNOPwJw0mn3PVLwUm59e5/mus5gM k+d3jnz1yEjoI9fzA+YsM2KGV8L1hcORspj6kl/fIzwbLayOutjYB3N8yrQyLOeurScjLjaTgwcY CvcOfigM+Vov3BiK9okZXgnXFw5HymLqS0FD720vHhKejSls6ocJffEJz71nu+pgYQs5LBjLzLWo J4a2C0N+1mtwuzAa+xcxyyvh+sLhSPFyfZkdPbx8cNu8vmwTxuLXilleCdcXDkeKd+vL3Jyx5eyQ 34+hLFaV+finxq/VYoZXwvWFw5Hi7foCTB2XJzK24DL3VIhJ3grXFw5HygL0ZXbW4vASs93Tl1mL xeFluVHNzcyajV9nT1UdxmVsTrOYp8V0r2Sh+lJWVuZvQ7RdUV9fHxISAv+IiAgxifP9QqvVxsfH BwUF0cLARF+6dEnMW1QWuvY8w7W+VFwZCjld9+Kn5x55O9nBtSnpya1pAaqqK71jmpYBh/oSp2mb mDYllGtfP1a4er967YFc2bXmgPqFqPPBuXUFbX0ypTFoQunlyHp9JEzmL+1w3CJLrS8kLmAp9OUb WHBUPxoS7W8VrwqGgLgwZZGyFEF+A9MNnOkLjhV+Jyru3BAnrIgUnomwfq7Ap6NrWfg9ryXA+Y6N h2X6cv+OxN0ZVa8cunD3dhWue32VrkR8Puyf8m5yycjk/CHFYhmNe3pw/udHQ77CtYNPzFlmxVzv Y6n1hZy/uw80qt9LtrRXBUOoVCqEBImB0MDEZ2pq6rlz5yj3u4gzfYnKaRbWRAk+0T97JR7nl6P5 bWdKO+yv0PSGZ3Zl3fZCnLA+5ofPx+JTqi8P+ac8FpD64K7kjTF5hzSteS299lduUzc0aNmXWXC7 b0filqSSGXrtssyOxv5p0FeiL9F/WPRfsTOaZ+v0V5Xf0BbALeoLM3FCppvY2Njh4WHKpRSCzi/M H+uSnnvkj3TcUBbSURurBECeQkNDKRc3WMFUhFIIJMITn7iHD9WGqtAQSycfZkqPVHiPYwHgBiYS ySSk8bOCLAaZKesdsvDJhgjhKQmuk3GgREJ2GGTtMmdqC59kwoENIOonLaB0pHjQHQbKIp015BCM NhXHYZZNAaBZkE0WVUizBjARMAFiloUHHM4aodSoSxT15er49N2vnRTWHrzrb8dLWgfEVGVOaXR3 4OVofYy9vkA19qrrps0udKH72vUN0Xnwf3R3ikZra9GqL39ean0xGM0Jl65Iv0jymMXSFylsvYq2 DUq096eliZXBNgAB01aHVVzEpHno8SiritYQLVkp5EzpbJ2RyeJE67QWGRSVaNiQxs8KuhwNtvFk vQNwpiwpTsZBtG2wABj0HsoODtQdUjHUaSt0AziTTHjcHQZSkI7m0BaTLSlQCirLkM2CFMQPcIMI yScjIwMmDYIsPKVZA04adYmivpwu0Vt/GdfnIN56xCRX/CvsovW8c7O+/GZn0poDatOMWy81FR1D OOzglSo4t85qu9IXvMGpCrVfnamPyGral1qbU9mFxLzann2n6yKzm5GCexyFkora92c0hmc07kur 1w2MJ1zSssMKulnfMVLQ0IuUzIpOFAnPavosuabI1oXUYj0qR1XBqbUVV4aQgrJfpdXDx9pcVZdM kxZLX2hlsxVDuYBMuJEp83f4GKcVBmi90gPKfmUDWTCAAsCyw+LDFmLtUjpbZGSyfUWbBIsYRQBz A0gHsvhdbkhZ76hH7OFPrTPhUEI2DoBMFowUqhNN4J4UmW1RGkDEjNbZnqQIPeuOFPtNjtqYJyJH CiKhLrAKpeMgmyzckA8SYZLaSqMFuAdKs+a8UZco6sunKTXCqijhudgqrVsVAbxACWsOyr5/uddX 5Z9eSQ4umZg2rYvIfWBn4sux+dYXFlf60n118nfvpV5u6m/oGMmr7fY7UTkyMb3645zUYl1xy0Ba id4nIKele/SPH509Xay/0jcGhz0pNR8cLs0o70Bx/cDEuk/UrT2j78RomjqvLffLLGsb1PaNQZV8 j5Wj4yt2ZamrulAVurY2IAc+PoHqwsY+W3M9b0cVyXRzsfSFTEyh1ARk0tIBMn8lyIdK0TLCcsEN 1hCWGlso9rXRkmUbhkHpbAnK3GiHONw/SAey+F1uSDIZ1AV7xGxlyI21LjOl0KYCuKHm2CuGdIsC khsaCs+6IwNCgBYxQeRMUJBoVLRvhnKVJovFzzpFMy6LR2nWnDfqEkV9+fBoGfTlJ3890tw1Kia5 4mJjn8OfH8VcbiUHd3jz+OX7diSuC8+1fgXjSl/warPjeEXwqZrPUmp2HivfnVBV3T68zC8zQFXl f7IyUFX1flxJ5ZWhd2OLzbbXn/5rhraeUQjNxr3nJ6fN7x8qwfFn3GCC4mia+987VELVAiTiaLNi VzZVFZBgrQp6tOtEZXBKLURqR3zZblWl+D3RPIurL8ChyabW3p/AGqVtIIVK2T8h6ZGFLPvalJYs pdOmYiZzs1ahsP5kWdTiQjck/Cldhpgtwck4AJkpgwrihYKGi57ewFboRinpUFDAC+2OExA/CQ00 Aia1ZQ8FI5sFBjt/0csRHcqALB66p6qkOG/UJYr68t9ojbAy8pf/PNk5dF1MckWd/ir0SFgXLdWX u7erTpReIQd3IH1ZtV/tjr5gw0MUOgYncNW2D6/enV3SOvDy5/mNHSO9I5O6/vE9ydW1uqvQEZkQ hGU0vBySvymyCG9YQ2NTm6Ot55dV/tlNnSNdw9ertcNQHJxlXgrJw3Gm79pkW/doYGJ1advgx4lV nYMT+sEJyNb6oFyIlFijDS/RF5mCEKwU1AT3WDeAPB0emAGtLfslS+nskS5zoy3BnvBSkA5k8WMn S03g0GRIjwzOcT4OMlOG9LnNIgSkbqx39ueXhXbHOdKxJYGwnw5CNgtSaBzok51QZPEozZrzRl2i qC9bYopt+nLCfX2pV9CX40umL0bz7OG8tv3pDQGJVeEZDSkaHd6q8up6IjMbPz1Vs/9sA44nkID8 OuvXK1Impkyfn6nDQQb3OASdq+mGQ0Z5Jyr5JKl63+laFEFWWqkeVe1Jrgk7W59e3oHmjuS1HUBz KltzRe1L9P0LmcChCTcyHS5ZPPQokR65zGSlGHCQripWG3tjUlqylI6yqAHO9KhnbnQgRyKyAO09 AunAfolTbFQQyHLJZNCKx25B18QkR7gcBzIdvscBRE4OQLrrHH7/gpCQ5Vl3pKBC1CwdH5ogknLW BXsVAE70hX1Bi2jFJLt4lGbNnUaBaNuhqC/b48uF1VG3b4hr6LD+Yy7uoPT7u9EL+fuAN45Z9QUF 3dEXb8NLzi+0KGVQKawS2hIMmFhPyMI+FJPmH8hKS5a1K4W5oR5ZE3S8Bywwcka7Mk+CnJV6h1Ky DsJkYyLFyThIcx3uScAEgsaHYPuNgXrIwbPuMOz7RaBOkkhA6sZAFkkbcKIvLGY2EUAWj5NZc9ko INMeRX0JTq21fb8bQz9JcYdodQskSfbzo/t8E7efKScHl4wajCvDch7YmfRqXIE73+96G174/Qvb JHDGCsbKYFkASwfOYjGJ+jjXFwBP2gz4hIPMDXWyRSltAjdUijmzUNEuK0JZSr0D2AzoF4VKBaW9 YLDKgXQcWK4sGBn02JfuSQI1sGrRNNv8wLPuMFAVGmWVIzy0LlU33GNSKGyAyNlhx8lkASrC+g7s 40HwLGbpkLpsFJBpj6K+ZFd2/uDZGGHtwTfDC8UkV6zanQ1/+c+n/ZKWfZk1NmUkH+dcaOt9dHfK /TsSQ/MbrPb3XV84Xgs7TSi9QHHcQVFfxg2mhzYlQS/u3BAXkdk0ZnD2X5cMj09/dLRMWBctrHfw +7u/9UvanKjRDY+TsxIa7cCqMPWDu5IfC0it7rpqTeL6wvk2YI9lSIyYxPEIRX0ByUXttz8Xa/2V Fp/oxzanrAtUbz1SGny6LjyrKTK7+Yu0+j3JNe/EaNYGqh/8d5KwMvIXfz/+ow1xsu9foBdPf5kJ iXlyb/rrxwr90yvDC5qOFrepKtpxJVS0x2naArOq/3Hk4uOBqXDD4WWvum6Wvo+1WEZjn7rp74+i fg/RsWZ5JVxfvh+QvkBc2DsCxzOc6QtIKdI9vjkFkiEsjxCWh1v/ylF2IXFZuLA6Ci9Hh/Narb/y uyKyoMH67++OTZmWh2b//IMTYRcaP8upfdg/5VfbEn69LYH+0PEe20X3uJAOcXlqX2Z0YYsoLjau n9858MH8309vFcbPviVmeCVcXzgcKS70BRiMM+llHZ+n1m6JKX71iwvP7znnE6he5pe5Pih34968 tyIvByVWn9LozDOzPVcng5KrAxOr6EfaRvNMQoU2NL+husv6BVWpbjDmcusnWdX/Syn9j0qDs8wb xws3qzTvJpfsSq88UNB0pqbjxl9Oz2Mxjk8Whkyc3TSRtmmyIGjWYHtv8la4vnA4UlzrC8d9uL5w OFK4viwmXF84HCmivnR1dXF9uUVMJpNerxcNDofD9GVsbGxgYMBs/g78H6xeC8awu7tbNDgcDtMX i8XS29s7PDxsMBiMRiMexRz3mZ6ehrjg5QhDR+PJ4XCAqC8AEjMyMoJNgkN+O8dtdDodPnH64+LC 4ci4oS8cDoezuHB94XA4S8Pc3P8BAs+M9iABHg0AAAAASUVORK5CYII= --94eb2c0cbf7abf4847053df88e46--