If ACID is needed, then C* is the wrong architecture. Your architecture needs to match to your business processes as Ben pointed out: "Ask if it’s really needed"
There is a concept of a velocity file (modern tech is memSQL'ish) that delivers the high performance, acid transactions of lambda architectures. It means the architecture is designed to support ONLY those functions that need to be acid'ic. FYI, velocity files are the ultra-fast record of ATM transactions that "just" happened, and are slowly replicated to the persistent account balances. So again, design your application architecture to support your needs. C* is BASIC. Learn to love it. It is basically your friend in big data, high volume ANSI SQL solutions. <======> "When I finish a project for a client, I have ... learned their issues with life, their personal secrets, I have come to care about them. Once the project is over, I lose them as if I lost family. For the client, however, they’ve just dismissed a service worker." ... "Thought on the Gig Economy" by Francine Brevetti On Wed, Apr 25, 2018 at 8:33 PM, Ben Slater <ben.sla...@instaclustr.com> wrote: > Would be interested to hear if anyone else has any different approaches > but my approaches would be: > 1) Ask if it’s really needed - in the example you gave would it really > matter that, for a small period of time, the hotel appeared in once kind of > search but not another? (Although clearly there are examples where it might > matter.) > 2) Put the state that matters in a single table. In this example, have a > hotel_enabled table. Search would have to both find the hotel in one of > your hotel_by_* tables and then look up the hotel in hotel_enabled to > check it is really enabled. “deleting” a hotel is then a single write to > hotel_enabled. hotel_enabled could also be something like hotel_details so > the other tables really are just indexes. You need to do more reads but > whatever you do consistency doesn’t come for free. > > Cheers > Ben > > > On Thu, 26 Apr 2018 at 12:44 Rajesh Kishore <rajesh10si...@gmail.com> > wrote: > >> Correction from previous query >> >> >> Thanks Ben and all experts. >> >> I am almost a newbie to NoSQL world and thus I have a very general >> question how does consumer application of Cassandra/other NoSQL >> technologies deal with atomicity & other factors when there is need to >> *de-normalize >> *data. For example: >> >> Let us say I have requirement for queries >> - find all hotels by name >> - Find all hotels by Point of Interest (POI) >> - Find POI near by a hotel >> >> For these queries I would end up more or less in following tables >> hotels_by_name(hotel_name,hotel_id,city,........) primary key - >> hotel_name >> hotels_by_poi(poi_name,poi_id,hotel_id,hotel_name,......) primary key - >> poi_name >> poi_by_hotel(hotel_id,poi_name,poi_id,poi_loc,hotel_name,......) primary >> key - hotel_id >> >> So, If I have to add/remove a hotel from/into hotels_by_name , I may need >> to add/remove into/from tables hotels_by_poi/poi_by_hotel. So, here my >> assumption is these operations would need to be atomic( and may be >> supporting other ACID properties) . How these kind of operations/usecases >> being handled in Cassandra/NoSQL world? >> >> Appreciate your response. >> >> Thanks, >> Rajesh >> >> On Thu, Apr 26, 2018 at 8:05 AM, Rajesh Kishore <rajesh10si...@gmail.com> >> wrote: >> >>> Thanks Ben and all experts. >>> >>> I am almost a newbie to NoSQL world and thus I have a very general >>> question how does consumer application of Cassandra/other NoSQL >>> technologies deal with atomicity & other factors when there is need to >>> normalize data. For example: >>> >>> Let us say I have requirement for queries >>> - find all hotels by name >>> - Find all hotels by Point of Interest (POI) >>> - Find POI near by a hotel >>> >>> For these queries I would end up more or less in following tables >>> hotels_by_name(hotel_name,hotel_id,city,........) primary key - >>> hotel_name >>> hotels_by_poi(poi_name,poi_id,hotel_id,hotel_name,......) primary key - >>> poi_name >>> poi_by_hotel(hotel_id,poi_name,poi_id,poi_loc,hotel_name,......) >>> primary key - hotel_id >>> >>> So, If I have to add/remove a hotel from/into hotels_by_name , I may >>> need to add/remove into/from tables hotels_by_poi/poi_by_hotel. So, here my >>> assumption is these operations would need to be atomic( and may be >>> supporting other ACID properties) . How these kind of operations/usecases >>> being handled in Cassandra/NoSQL world? >>> >>> Appreciate your response. >>> >>> Thanks, >>> Rajesh >>> >>> >>> >>> On Fri, Apr 20, 2018 at 11:07 AM, Ben Slater <ben.sla...@instaclustr.com >>> > wrote: >>> >>>> The second SO answer just says the partitions will be collocated (ie on >>>> the same server) not that the two tables will use the same partition. In >>>> any event, Cassandra does not have the kind of functionality you are >>>> looking for. The closest is logged batch but as Sylvain said, "all that >>>> guarantees is that if some operations of a batch are applied, then all >>>> of them will >>>> *eventually* get applied” and “batch have no rollback whatsoever”. >>>> >>>> As Cassandra won’t help you here, a potential (although admittedly more >>>> complex) option is to do implement compensating transactions at the >>>> application level (eg in the catch block delete the records that were >>>> inserted). That, however, does not provide you the isolation part of ACID. >>>> >>>> You also tend to find that if you have properly denormalised your data >>>> model for Cassandra there is less requirement for these type of batched >>>> updates. >>>> >>>> Cheers >>>> Ben >>>> >>>> On Fri, 20 Apr 2018 at 15:21 Rajesh Kishore <rajesh10si...@gmail.com> >>>> wrote: >>>> >>>>> Re-framing my question: >>>>> >>>>> So, it means that having different tables will not result into same >>>>> partition even though you have same partition key. >>>>> Ex. >>>>> TableA( Partionkey(id)) >>>>> TableB( Partionkey(id)) >>>>> TableC( Partionkey(id)) >>>>> >>>>> >>>>> and as part of batch operation I am somehow providing same id say "20" >>>>> It wont be considered as Atomic as it will result into different >>>>> partition key and there would not be any way to rollback ? >>>>> The same is being claimed in https://stackoverflow.com/ >>>>> questions/36700859/does-the-same-partition-key-in- >>>>> different-cassandra-tables-add-up-to-cell-theoret >>>>> >>>>> Now, the other forum says that how we can keep two tables in same >>>>> partition >>>>> https://stackoverflow.com/questions/34294830/how-to- >>>>> keep-2-cassandra-tables-within-same-partition >>>>> >>>>> Which one is correct ? Please confirm >>>>> >>>>> Basically , our requirement is - we should be able to achieve similar >>>>> functionality as that of JDBC >>>>> try { >>>>> txn.start() >>>>> operation a >>>>> operation b >>>>> >>>>> ...... >>>>> operation n >>>>> txn.commit(); >>>>> } catch (Exception e) >>>>> { >>>>> txn.rollback() >>>>> } >>>>> >>>>> Thanks in advance. >>>>> >>>>> Regards, >>>>> Rajesh >>>>> >>>>> On Fri, Apr 20, 2018 at 9:38 AM, Rajesh Kishore < >>>>> rajesh10si...@gmail.com> wrote: >>>>> >>>>>> So, it means that having different tables will not result into same >>>>>> partition even though you have same partition key. >>>>>> Ex. >>>>>> TableA( Partionkey(id)) >>>>>> TableB( Partionkey(id)) >>>>>> TableC( Partionkey(id)) >>>>>> >>>>>> >>>>>> and as part of batch operation I am somehow providing same id say "20" >>>>>> It wont be considered as Atomic as it will result into different >>>>>> partition key and there would not be any way to rollback ? >>>>>> The same is being claimed in https://stackoverflow.com/ >>>>>> questions/36700859/does-the-same-partition-key-in- >>>>>> different-cassandra-tables-add-up-to-cell-theoret >>>>>> >>>>>> Please confirm >>>>>> >>>>>> Thanks in advance. >>>>>> >>>>>> Regards, >>>>>> Rajesh >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Apr 19, 2018 at 3:10 PM, Jacques-Henri Berthemet < >>>>>> jacques-henri.berthe...@genesys.com> wrote: >>>>>> >>>>>>> When using BATCH on multiple tables you’ll need to use a LOGGED >>>>>>> batch. When you send the request, it will be written to the batch log of >>>>>>> all (relevant) nodes, when this write is successful it will be “ >>>>>>> accepted” and nodes will try to apply the batch operations. If for >>>>>>> any reason a statement fails the node will keep retrying forever. In >>>>>>> that >>>>>>> case you may see partially applied batch until it’s fixed. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Note that you can’t mix BATCH and LWT on different >>>>>>> tables/partitions. >>>>>>> >>>>>>> >>>>>>> >>>>>>> You can get more details here: >>>>>>> >>>>>>> http://cassandra.apache.org/doc/latest/cql/dml.html#batch >>>>>>> >>>>>>> https://inoio.de/blog/2016/01/13/cassandra-to-batch-or-not-to-batch/ >>>>>>> >>>>>>> *--* >>>>>>> >>>>>>> *Jacques-Henri Berthemet* >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* Rajesh Kishore [mailto:rajesh10si...@gmail.com] >>>>>>> *Sent:* Thursday, April 19, 2018 11:13 AM >>>>>>> *To:* user@cassandra.apache.org >>>>>>> >>>>>>> *Subject:* Re: Does Cassandra supports ACID txn >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks for the response. Let me put my question again wrt a example >>>>>>> >>>>>>> I want to perform a atomic txn say insert/delete/update on a set of >>>>>>> tables >>>>>>> >>>>>>> TableA >>>>>>> >>>>>>> TableB >>>>>>> >>>>>>> TableC >>>>>>> >>>>>>> When these are performed as batch operations and let us say >>>>>>> something goes wrong while doing operation at TableC >>>>>>> >>>>>>> Would the system rollback the operations done for TableA TableB ? >>>>>>> >>>>>>> -Rajesh >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Apr 19, 2018 at 1:25 PM, Jacques-Henri Berthemet < >>>>>>> jacques-henri.berthe...@genesys.com> wrote: >>>>>>> >>>>>>> Cassandra support LWT (Lightweight transactions), you may find this >>>>>>> doc interesting: >>>>>>> >>>>>>> https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/ >>>>>>> dmlDataConsistencyTOC.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> In any case, LWT or BATCH you won’t have external control on the >>>>>>> tx, it’s either done or not done. In case of timeout you won’t have >>>>>>> a way to know if it worked or not. >>>>>>> >>>>>>> There is no way to rollback a statement/batch, the only way is to >>>>>>> send an update to modify the partition to its previous state. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> *--* >>>>>>> >>>>>>> *Jacques-Henri Berthemet* >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* DuyHai Doan [mailto:doanduy...@gmail.com] >>>>>>> *Sent:* Thursday, April 19, 2018 9:10 AM >>>>>>> *To:* user <user@cassandra.apache.org> >>>>>>> *Subject:* Re: Does Cassandra supports ACID txn >>>>>>> >>>>>>> >>>>>>> >>>>>>> No ACID transaction any soon in Cassandra >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Apr 19, 2018 at 7:35 AM, Rajesh Kishore < >>>>>>> rajesh10si...@gmail.com> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I am bit confused by reading different articles, does recent version >>>>>>> of Cassandra supports ACID transaction ? >>>>>>> >>>>>>> I found BATCH command , but not sure if it supports rollback, >>>>>>> consider that transaction I am going to perform would be on single >>>>>>> partition. >>>>>>> >>>>>>> Also, what are the limitations if any? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Rajesh >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> -- >>>> >>>> >>>> *Ben Slater* >>>> >>>> *Chief Product Officer <https://www.instaclustr.com/>* >>>> >>>> <https://www.facebook.com/instaclustr> >>>> <https://twitter.com/instaclustr> >>>> <https://www.linkedin.com/company/instaclustr> >>>> >>>> Read our latest technical blog posts here >>>> <https://www.instaclustr.com/blog/>. >>>> >>>> This email has been sent on behalf of Instaclustr Pty. Limited >>>> (Australia) and Instaclustr Inc (USA). >>>> >>>> This email and any attachments may contain confidential and legally >>>> privileged information. If you are not the intended recipient, do not copy >>>> or disclose its content, but please reply to this email immediately and >>>> highlight the error to the sender and then immediately delete the message. >>>> >>> >>> >> -- > > > *Ben Slater* > > *Chief Product Officer <https://www.instaclustr.com/>* > > <https://www.facebook.com/instaclustr> <https://twitter.com/instaclustr> > <https://www.linkedin.com/company/instaclustr> > > Read our latest technical blog posts here > <https://www.instaclustr.com/blog/>. > > This email has been sent on behalf of Instaclustr Pty. Limited (Australia) > and Instaclustr Inc (USA). > > This email and any attachments may contain confidential and legally > privileged information. If you are not the intended recipient, do not copy > or disclose its content, but please reply to this email immediately and > highlight the error to the sender and then immediately delete the message. >
