1
2.. _known-limitations:
3
4#################
5Known Limitations
6#################
7
8.. include:: guide-common.rst.inc
9
10FoundationDB has limitations, some of which may be addressed in future versions.
11
12For related information, also see:
13 * :doc:`platforms` that affect the operation of FoundationDB.
14 * :ref:`system-requirements` for OS/hardware requirements.
15 * :doc:`anti-features` for limitations of the scope of the FoundationDB core.
16 * :ref:`developer-guide-peformance-considerations` for how different workloads can limit performance.
17
18Design limitations
19==================
20
21These limitations come from fundamental design decisions and are unlikely to change in the short term. Applications using FoundationDB should plan to work around these limitations. See :doc:`anti-features` for related discussion of our design approach to the FoundationDB core.
22
23.. _large-transactions:
24
25Large transactions
26------------------
27
28Transaction size cannot exceed 10,000,000 bytes of affected data. Keys, values, and ranges that you write are included as affected data. Keys and ranges that you read are also included as affected data, but values that you read are not. Likewise, conflict ranges that you :ref:`add <api-python-conflict-ranges>` or remove (using a :ref:`snapshot read <api-python-snapshot-reads>` or a :ref:`transaction option <api-python-no-write-conflict-range>`) are also added or removed from the scope of affected data.
29
30If any single transaction exceeds one megabyte of affected data, you should modify your design. In the current version, these large transactions can cause performance issues and database availability can (briefly) be impacted.
31
32.. admonition:: Workarounds
33
34    See the discussion in :ref:`long transactions <long-transactions>` for applicable workarounds.
35
36.. _large-keys-and-values:
37
38Large keys and values
39---------------------
40
41Keys cannot exceed 10,000 bytes in size. Values cannot exceed 100,000 bytes in size. Errors will be raised by the client if these limits are exceeded.
42
43.. admonition:: Workarounds
44
45    FoundationDB provides efficient ways to :doc:`design keys and values<largeval>` to work around this limitation.
46
47.. _spinning-HDDs:
48
49Spinning HDDs
50-------------
51
52FoundationDB is only designed for good performance with rotational disk drives when using the durable :ref:`memory <configuration-storage-engine-memory>` storage engine. It is not recommended that you run FoundationDB on rotational HDDs when using the :ref:`ssd <configuration-storage-engine-ssd>` storage engine. Many algorithms and optimizations have been made to specifically target good performance on solid-state storage that do not translate well to HDDs. Reduced performance and/or database availability issues can be expected.
53
54.. admonition:: Recommendation
55
56    Large disk arrays and abstracted storage subsystems with sufficient I/O performance may be able to overcome this limitation, but testing specific use cases will be required.
57
58.. _dont-use-key-selectors-for-paging:
59
60Key selectors with large offsets are slow
61-----------------------------------------
62
63The current version of FoundationDB resolves key selectors with large offsets in O(offset) time. A common misusage of key selectors is using offsets to page through a large range of data (i.e. reading 'a'+0 to 'a'+100, then 'a'+100 to 'a'+200, etc.)
64
65.. admonition:: Workarounds
66
67    An efficient alternative is to use the limit parameter with range reads, starting subsequent reads at the key after the last one returned. You can also use the iterator functionality available in most of the language bindings, which uses this technique internally.
68
69    The RankedSet layer provides a data structure in which large offsets and counting operations require only O(log N) time. It is a good choice for applications such as large leaderboards that require such functionality.
70
71Not a security boundary
72-----------------------
73
74Anyone who can connect to a FoundationDB cluster can read and write every key in the database. There is no user-level access control. External protections must be put into place to protect your database.
75
76Current limitations
77===================
78
79These limitations do not reflect fundamental aspects of our design and are likely to be resolved or mitigated in future versions. Administrators should be aware of these issues, but longer-term application development should be less driven by them.
80
81.. _long-transactions:
82
83Long running transactions
84-------------------------
85
86FoundationDB currently does not support transactions running for over five seconds. In particular, after 5 seconds from the first read in a transaction:
87
88* subsequent reads that go to the database will usually raise a ``transaction_too_old`` :doc:`error <api-error-codes>` (although reads cached by the client will not);
89* a commit with any write will raise a ``transaction_too_old`` or ``not_committed`` :doc:`error <api-error-codes>`.
90
91Long running read/write transactions are a design limitation, see the discussion in :doc:`anti-features`.
92
93.. admonition:: Workarounds
94
95    The effect of long and large transactions can be achieved using short and small transactions with a variety of techniques, depending on the desired behavior:
96
97    * If an application wants long transactions because of an external process in the loop, it can perform optimistic validation itself at a higher layer.
98    * If it needs long-running read snapshots, it can perform versioning in a layer.
99    * If it needs large bulk inserts, it can use a level of indirection to swap in the inserted data quickly.
100
101.. _cluster-size:
102
103Cluster size
104------------
105
106FoundationDB has undergone performance testing and tuning with clusters of up to 500 cores/processes. Significantly larger clusters may experience performance bottlenecks leading to sub-linear scaling or related issues.
107
108Database size
109-------------
110
111FoundationDB has been tested with databases up to 100 TB (total size of key-value pairs -- required disk space will be significantly higher after replication and overhead).
112
113Limited read load balancing
114---------------------------
115
116FoundationDB load balances reads across the servers with replicas of the data being read. However, it does not currently increase the replication factor of keys that are frequently read. As a result, the aggregate read performance of any given key or small contiguous set of keys in a triple-replicated system is limited to the total performance of three server processes (typically on the order of 100,000 reads per second).
117
118.. admonition:: Workarounds
119
120    If data is accessed exceptionally frequently, an application could avoid this limitation by storing such data in multiple subspaces, effectively increasing its replication factor.
121
122
123