MongoDB, E-commerce and Transactions

Editor's Notes

• #2: \n
• #3: \n
• #4: \n
• #5: \n
• #6: \n
• #7: \n
• #8: \n
• #9: \n
• #10: \n
• #11: \n
• #12: \n
• #13: \n
• #14: Remember in 1995 there were around 10,000 websites. Mosiac, Lynx, Mozilla (pre netscape) and IE 2.0 were the only web browsers. \nApache (Dec ’95), Java (’96), PHP (June ’95), and .net didn’t exist yet. Linux just barely (1.0 in ’94)\n
• #15: Remember in 1995 there were around 10,000 websites. Mosiac, Lynx, Mozilla (pre netscape) and IE 2.0 were the only web browsers. \nApache (Dec ’95), Java (’96), PHP (June ’95), and .net didn’t exist yet. Linux just barely (1.0 in ’94)\n
• #16: Remember in 1995 there were around 10,000 websites. Mosiac, Lynx, Mozilla (pre netscape) and IE 2.0 were the only web browsers. \nApache (Dec ’95), Java (’96), PHP (June ’95), and .net didn’t exist yet. Linux just barely (1.0 in ’94)\n
• #17: \n
• #18: \n
• #19: \n
• #20: \n
• #21: By reducing transactional semantics the db provides, one can still solve an interesting set of problems where performance is very important, and horizontal scaling then becomes easier.\n\n
• #22: \n
• #23: \n
• #24: \n
• #25: \n
• #26: \n
• #27: \n
• #28: \n
• #29: \n
• #30: \n
• #31: \n
• #32: \n
• #33: \n
• #34: \n
• #35: \n
• #36: \n
• #37: \n
• #38: \n
• #39: \n
• #40: \n
• #41: \n
• #42: \n
• #43: \n
• #44: \n
• #45: \n
• #46: \n
• #47: \n
• #48: \n
• #49: \n
• #50: \n
• #51: actually, just the first 1/3 of it. \n
• #52: \n
• #53: Ironically this is how magento solves the performance problems associated with EAV, by caching the data into insanely wide tables.\n
• #54: \n
• #55: \n
• #56: \n
• #57: Can’t create a FK as each set references a different table. “Key” really made of attribute table name id and attribute table name\n
• #58: \n
• #59: \n
• #60: \n
• #61: \n
• #62: \n
• #63: \n
• #64: \n
• #65: \n
• #66: \n
• #67: \n
• #68: \n
• #69: \n
• #70: \n
• #71: \n
• #72: \n
• #73: \n
• #74: \n
• #75: \n
• #76: \n
• #77: \n
• #78: Whenever you use a inter system coordination you need to implement your own atomic checks in the application... But SOAP does have transactions.. so not quite accurate. \n\nkyle idea... but we are fairly atomic with authorize.net\n\natomicity, consistency, isolation, durability.\n\n
• #79: Whenever you use a inter system coordination you need to implement your own atomic checks in the application... But SOAP does have transactions.. so not quite accurate. \n\nkyle idea... but we are fairly atomic with authorize.net\n\natomicity, consistency, isolation, durability.\n\n
• #80: atomicity, consistency, isolation, durability.\n\n
• #81: atomicity, consistency, isolation, durability.\n\n
• #82: Mongo has a grip of atomic operations: set, unset, etc.\n
• #83: Mongo has a grip of atomic operations: set, unset, etc.\n
• #84: Mongo has a grip of atomic operations: set, unset, etc.\n
• #85: \n
• #86: \n
• #87: update( { where }, { values }, upsert?, multiple? )\n\nIsolated is not atomic. Atomic implies that there is an all-or-nothing semantic to the update; this is not possible with more than one document. Isolated just means than you are the only one writing when the update is done; this means each update is done without any interference from any other.\n\nMongoDB supports atomic operations on single documents.  MongoDB does not support traditional locking and complex transactions for a number of reasons:\nFirst, in sharded environments, distributed locks could be expensive and slow.  Mongo DB's goal is to be lightweight and fast.\nWe dislike the concept of deadlocks.  We want the system to be simple and predictable without these sort of surprises.\nWe want Mongo DB to work well for realtime problems.  If an operation may execute which locks large amounts of data, it might stop some small light queries for an extended period of time.  (We don't claim Mongo DB is perfect yet in regards to being "real-time", but we certainly think locking would make it even harder.)\n\n\n\n
• #88: update( { where }, { values }, upsert?, multiple? )\n\nIsolated is not atomic. Atomic implies that there is an all-or-nothing semantic to the update; this is not possible with more than one document. Isolated just means than you are the only one writing when the update is done; this means each update is done without any interference from any other.\n\nMongoDB supports atomic operations on single documents.  MongoDB does not support traditional locking and complex transactions for a number of reasons:\nFirst, in sharded environments, distributed locks could be expensive and slow.  Mongo DB's goal is to be lightweight and fast.\nWe dislike the concept of deadlocks.  We want the system to be simple and predictable without these sort of surprises.\nWe want Mongo DB to work well for realtime problems.  If an operation may execute which locks large amounts of data, it might stop some small light queries for an extended period of time.  (We don't claim Mongo DB is perfect yet in regards to being "real-time", but we certainly think locking would make it even harder.)\n\n\n\n
• #89: update( { where }, { values }, upsert?, multiple? )\n\nIsolated is not atomic. Atomic implies that there is an all-or-nothing semantic to the update; this is not possible with more than one document. Isolated just means than you are the only one writing when the update is done; this means each update is done without any interference from any other.\n\nMongoDB supports atomic operations on single documents.  MongoDB does not support traditional locking and complex transactions for a number of reasons:\nFirst, in sharded environments, distributed locks could be expensive and slow.  Mongo DB's goal is to be lightweight and fast.\nWe dislike the concept of deadlocks.  We want the system to be simple and predictable without these sort of surprises.\nWe want Mongo DB to work well for realtime problems.  If an operation may execute which locks large amounts of data, it might stop some small light queries for an extended period of time.  (We don't claim Mongo DB is perfect yet in regards to being "real-time", but we certainly think locking would make it even harder.)\n\n\n\n
• #90: update( { where }, { values }, upsert?, multiple? )\n\nIsolated is not atomic. Atomic implies that there is an all-or-nothing semantic to the update; this is not possible with more than one document. Isolated just means than you are the only one writing when the update is done; this means each update is done without any interference from any other.\n\nMongoDB supports atomic operations on single documents.  MongoDB does not support traditional locking and complex transactions for a number of reasons:\nFirst, in sharded environments, distributed locks could be expensive and slow.  Mongo DB's goal is to be lightweight and fast.\nWe dislike the concept of deadlocks.  We want the system to be simple and predictable without these sort of surprises.\nWe want Mongo DB to work well for realtime problems.  If an operation may execute which locks large amounts of data, it might stop some small light queries for an extended period of time.  (We don't claim Mongo DB is perfect yet in regards to being "real-time", but we certainly think locking would make it even harder.)\n\n\n\n
• #91: update( { where }, { values }, upsert?, multiple? )\n\nIsolated is not atomic. Atomic implies that there is an all-or-nothing semantic to the update; this is not possible with more than one document. Isolated just means than you are the only one writing when the update is done; this means each update is done without any interference from any other.\n\nMongoDB supports atomic operations on single documents.  MongoDB does not support traditional locking and complex transactions for a number of reasons:\nFirst, in sharded environments, distributed locks could be expensive and slow.  Mongo DB's goal is to be lightweight and fast.\nWe dislike the concept of deadlocks.  We want the system to be simple and predictable without these sort of surprises.\nWe want Mongo DB to work well for realtime problems.  If an operation may execute which locks large amounts of data, it might stop some small light queries for an extended period of time.  (We don't claim Mongo DB is perfect yet in regards to being "real-time", but we certainly think locking would make it even harder.)\n\n\n\n
• #92: update( { where }, { values }, upsert?, multiple? )\n\nIsolated is not atomic. Atomic implies that there is an all-or-nothing semantic to the update; this is not possible with more than one document. Isolated just means than you are the only one writing when the update is done; this means each update is done without any interference from any other.\n\nMongoDB supports atomic operations on single documents.  MongoDB does not support traditional locking and complex transactions for a number of reasons:\nFirst, in sharded environments, distributed locks could be expensive and slow.  Mongo DB's goal is to be lightweight and fast.\nWe dislike the concept of deadlocks.  We want the system to be simple and predictable without these sort of surprises.\nWe want Mongo DB to work well for realtime problems.  If an operation may execute which locks large amounts of data, it might stop some small light queries for an extended period of time.  (We don't claim Mongo DB is perfect yet in regards to being "real-time", but we certainly think locking would make it even harder.)\n\n\n\n
• #93: \n
• #94: \n
• #95: MongoDB supports atomic operations on single documents.  MongoDB does not support traditional locking and complex transactions for a number of reasons:\nFirst, in sharded environments, distributed locks could be expensive and slow.  Mongo DB's goal is to be lightweight and fast.\nWe dislike the concept of deadlocks.  We want the system to be simple and predictable without these sort of surprises.\nWe want Mongo DB to work well for realtime problems.  If an operation may execute which locks large amounts of data, it might stop some small light queries for an extended period of time.  (We don't claim Mongo DB is perfect yet in regards to being "real-time", but we certainly think locking would make it even harder.)\n\n
• #96: MongoDB supports atomic operations on single documents.  MongoDB does not support traditional locking and complex transactions for a number of reasons:\nFirst, in sharded environments, distributed locks could be expensive and slow.  Mongo DB's goal is to be lightweight and fast.\nWe dislike the concept of deadlocks.  We want the system to be simple and predictable without these sort of surprises.\nWe want Mongo DB to work well for realtime problems.  If an operation may execute which locks large amounts of data, it might stop some small light queries for an extended period of time.  (We don't claim Mongo DB is perfect yet in regards to being "real-time", but we certainly think locking would make it even harder.)\n\n
• #97: MongoDB supports atomic operations on single documents.  MongoDB does not support traditional locking and complex transactions for a number of reasons:\nFirst, in sharded environments, distributed locks could be expensive and slow.  Mongo DB's goal is to be lightweight and fast.\nWe dislike the concept of deadlocks.  We want the system to be simple and predictable without these sort of surprises.\nWe want Mongo DB to work well for realtime problems.  If an operation may execute which locks large amounts of data, it might stop some small light queries for an extended period of time.  (We don't claim Mongo DB is perfect yet in regards to being "real-time", but we certainly think locking would make it even harder.)\n\n
• #98: MongoDB supports atomic operations on single documents.  MongoDB does not support traditional locking and complex transactions for a number of reasons:\nFirst, in sharded environments, distributed locks could be expensive and slow.  Mongo DB's goal is to be lightweight and fast.\nWe dislike the concept of deadlocks.  We want the system to be simple and predictable without these sort of surprises.\nWe want Mongo DB to work well for realtime problems.  If an operation may execute which locks large amounts of data, it might stop some small light queries for an extended period of time.  (We don't claim Mongo DB is perfect yet in regards to being "real-time", but we certainly think locking would make it even harder.)\n\n
• #99: \n
• #100: lemme show you an example\n
• #101: lemme show you an example\n
• #102: or instead of qty, use an version_id.\n object id / md5 as a version. \n
• #103: or instead of qty, use an version_id.\n object id / md5 as a version. \n
• #104: or instead of qty, use an version_id.\n object id / md5 as a version. \n
• #105: or instead of qty, use an version_id.\n object id / md5 as a version. \n
• #106: \n
• #107: Imagine what would happen if everyone tried to access the same record at the same time. Just think of all those spinning while loops :)\n
• #108: \n
• #109: \n
• #110: \n
• #111: \n
• #112: \n
• #113: \n
• #114: \n
• #115: \n
• #116: \n
• #117: \n
• #118: \n
• #119: \n
• #120: Mind if I tell you a story?\n
• #121: \n
• #122: \n
• #123: \n
• #124: \n
• #125: \n
• #126: \n
• #127: \n
• #128: \n
• #129: \n
• #130: \n
• #131: \n
• #132: By using a single document we avoid any need for complicated transactions. \n Any number of concurrent read operations are allowed, but typically only one write operation (although some write operations yield and in the future more concurrency will be added). The write lock acquisition is greedy: a pending write lock acquisition will prevent further read lock acquisitions until fulfilled.\n
• #133: By using a single document we avoid any need for complicated transactions. \n Any number of concurrent read operations are allowed, but typically only one write operation (although some write operations yield and in the future more concurrency will be added). The write lock acquisition is greedy: a pending write lock acquisition will prevent further read lock acquisitions until fulfilled.\n
• #134: By using a single document we avoid any need for complicated transactions. \n Any number of concurrent read operations are allowed, but typically only one write operation (although some write operations yield and in the future more concurrency will be added). The write lock acquisition is greedy: a pending write lock acquisition will prevent further read lock acquisitions until fulfilled.\n
• #135: By using a single document we avoid any need for complicated transactions. \n Any number of concurrent read operations are allowed, but typically only one write operation (although some write operations yield and in the future more concurrency will be added). The write lock acquisition is greedy: a pending write lock acquisition will prevent further read lock acquisitions until fulfilled.\n
• #136: By using a single document we avoid any need for complicated transactions. \n Any number of concurrent read operations are allowed, but typically only one write operation (although some write operations yield and in the future more concurrency will be added). The write lock acquisition is greedy: a pending write lock acquisition will prevent further read lock acquisitions until fulfilled.\n
• #137: By using a single document we avoid any need for complicated transactions. \n Any number of concurrent read operations are allowed, but typically only one write operation (although some write operations yield and in the future more concurrency will be added). The write lock acquisition is greedy: a pending write lock acquisition will prevent further read lock acquisitions until fulfilled.\n
• #138: \n
• #139: \n
• #140: \n
• #141: \n
• #142: \n
• #143: Inventory can be provided by using count. Can be cached as value on the sku.\nAs the items themselves are atomic, the order need not be to reserve inventory.\n
• #144: Inventory can be provided by using count. Can be cached as value on the sku.\nAs the items themselves are atomic, the order need not be to reserve inventory.\n
• #145: Inventory can be provided by using count. Can be cached as value on the sku.\nAs the items themselves are atomic, the order need not be to reserve inventory.\n
• #146: remember by default, update only updates 1 document and the operation is atomic on that document.\n\n
• #147: remember by default, update only updates 1 document and the operation is atomic on that document.\n\n
• #148: remember by default, update only updates 1 document and the operation is atomic on that document.\n\n
• #149: \n
• #150: \n