{"action":"opened","issue":{"url":"https://api.github.com/repos/YugaByte/yugabyte-db/issues/79","repository_url":"https://api.github.com/repos/YugaByte/yugabyte-db","labels_url":"https://api.github.com/repos/YugaByte/yugabyte-db/issues/79/labels{/name}","comments_url":"https://api.github.com/repos/YugaByte/yugabyte-db/issues/79/comments","events_url":"https://api.github.com/repos/YugaByte/yugabyte-db/issues/79/events","html_url":"https://github.com/YugaByte/yugabyte-db/issues/79","id":302558547,"number":79,"title":"Co-partitioned tables","user":{"login":"rkarthik007","id":9641328,"avatar_url":"https://avatars0.githubusercontent.com/u/9641328?v=4","gravatar_id":"","url":"https://api.github.com/users/rkarthik007","html_url":"https://github.com/rkarthik007","followers_url":"https://api.github.com/users/rkarthik007/followers","following_url":"https://api.github.com/users/rkarthik007/following{/other_user}","gists_url":"https://api.github.com/users/rkarthik007/gists{/gist_id}","starred_url":"https://api.github.com/users/rkarthik007/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rkarthik007/subscriptions","organizations_url":"https://api.github.com/users/rkarthik007/orgs","repos_url":"https://api.github.com/users/rkarthik007/repos","events_url":"https://api.github.com/users/rkarthik007/events{/privacy}","received_events_url":"https://api.github.com/users/rkarthik007/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-03-06T04:17:42Z","updated_at":"2018-03-06T04:17:42Z","closed_at":null,"author_association":"COLLABORATOR","body":"This is a feature request for implementing co-partitioned tables in order to achieve distributed transactions with high performance in certain scenarios. \r\n\r\nThis should allow creating a table A, and then creating another table B with the same partition key as A and specify that we want B to be co-partitioned with A. The two tables would share tablets, raft groups, load-balancing decisions, etc. And we should allow for updates to these tables to happen atomically if the update involves the same partition key (i.e. userid in our example above).\r\n\r\nFor example:\r\n```\r\nCREATE TABLE user (\r\n  userid int, \r\n  username text,\r\n  PRIMARY KEY (userid)\r\n);\r\n\r\nCREATE TABLE messages (\r\n  userid int,\r\n  msgid int,\r\n  msgtext text,\r\n  PRIMARY KEY ((userid), msgid)\r\n) with PARTITION SCHEME OF user;\r\n```\r\nThis should ensure that the `user` and `messages` tables have the same tablet splits with respect to the primary hash keys, and the tablets serving a given key range across the two tables are always colocated on the same node.\r\n\r\n## Background in other NoSQL systems:\r\n\r\n### Apache Cassandra\r\n\r\nIn Apache Cassandra, if two tables share the same replication strategy and same partition key they will co-locate their partitions. So as long as the two tables are in the same keyspace AND their partition keys match, for example:\r\n```\r\nCustomer table with PRIMARY KEY (customer_id)\r\n```\r\nand an\r\n```\r\nInvoice table with PRIMARY KEY ((customer_id), invoice_id)\r\n```\r\nThen, the data for a given customer_id across both tables is guaranteed to be colocated on the same set of nodes.\r\n\r\n### HBase\r\nIn HBase, co-partition happens across column families that share the same ROW KEY.\r\n\r\nAdditionally, in HBase, since a common WAL is shared for cross-column family mutations, we also guaranteed cross-column family atomicity.\r\n\r\n\r\n"}}
{"actor":{"display_login":"rkarthik007"}}