addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1light-bulblinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

September 2014 Meetup - Jim Fulton: ZODB

ZODB is an object database for Python. It provides a simple
programming model. Programmers work with data as if they had unlimited memory, with a transaction-based concurrency model spanning threads, processes and machines. It's mature and widely used technology.

Outline:
- Introduction
- Example application
- Quick usage demo.
- Architecture
- Advantages
- Disadvantages
- Comparison with other databases.

Join or login to comment.

  • Casey F.

    Hey everyone,

    Hope you are having a good week so far! I wanted to reach out since I am currently working on a great start up within a leading media company in McLean, VA. I am a recruiter with TEKsystems, and as someone who is looking extensively for a Python/Django developer, I figured this would be a great place to start! They are looking for someone to make an immediate impact since the prototype stage is only until mid January, where they will then determine the budget for the project. This position will attract anyone looking to work in a fast paced environment, get their hands dirty, and like the aspect of a start up feel. Please let me know if you or anyone else that is interested. They are able to high junior, but prefer someone with 3-5 years experience.

    Thanks for your time, and look forward to hearing from you.

    Casey
    [masked]

    October 21, 2014

  • Jennifer R.

    Hi guys,

    Last night Tim asked me a question about the number of simultaneous clients that FoundationDB supports, and I stumbled out an answer. I wanted to try and give a proper answer :)

    The largest test that we've run internally was on a FoundationDB cluster of 100 machines with 150 clients (in other words, simultaneous connections).

    In case you're interested, here's some info on the test:
    Platform: Ubuntu on EC2 m3.xlarge instances (4 vCPU, 15GB RAM, 2x40GB SSDs)
    Workload: All reads
    Result: 1.2M operations/second

    This test was run on FoundationDB 3, which hasn't been released yet. You can find more info on our performance of that release here, plus my thoughts on the scalability of ACID transactions: http://blog.foundationdb.com/on-lowered-expectations-transactions-scaling-and-honesty

    Hope that's a more interesting answer. Nice to see everyone!

    Jen

    September 3, 2014

    • A former member
      A former member

      Thanks. When I was asked the question, It was in reference to ZODB's choice to send an invalidation message to every client for every write. So the interesting metrics is number of clients * write rate. In our apps, we've had comparable #s of clients, I guess, but probably lower write rates than FoundationDB is designed to handle.

      1 · September 3, 2014

    • Jennifer R.

      Oh okay, that makes sense. The particular test I mentioned was all reads, but in the linked blog post there's a test with 36 clients that performed 600K random writes per second. It's not really a test of how many clients the database can handle though.

      With FoundationDB, when a client attempts to commit a write the database server checks whether any of the data read by that client's transaction has been modified by another transaction. If so the transaction fails with a conflict error.

      This approach means that FoundationDB can handle a lot of concurrent clients. But it has the drawback that the database has to remember what data has changed. FoundationDB remembers the last five seconds of history, so every client transaction has be shorter than five seconds. The five seconds is a bit arbitrary, but the design means that some limit is necessary. So FoundationDB is not a good fit for application with very long running transactions.

      September 8, 2014

  • A former member
    A former member

    September 7, 2014

  • A former member
    A former member

    A small clarification. When I searched for a release by name, someone asked me if the collection was loaded into memory, which it was. This app doesn't need search, but the demo did. And the database is pretty tiny (and will be when it's in production). In practice, with large collections, you'd use a BTree or a BTree-based data structure (e.g. generationalsets). When searching a BTree you don't load the entire tree into memory. You only load the BTree nodes needed to do the search, which is typically a very small fraction of the entire tree. Similarly, when walking an object tree, you only load the objects that you actually traverse.

    1 · September 3, 2014

  • Tino

    It was good, maybe a little long

    September 2, 2014

  • Alex C.

    Take pictures, please!

    September 2, 2014

Our Sponsors

  • O'Reilly

    The world’s most comprehensive technology and business learning platform

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy