├── LICENSE ├── README.md ├── diagram.png ├── roaringbitmap.ksy ├── roaringbitmap64.ksy └── testdata ├── README.md ├── bitmapwithoutruns.bin └── bitmapwithruns.bin /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "{}" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright {yyyy} {name of copyright owner} 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # RoaringFormatSpec : specification of the compressed-bitmap Roaring formats 2 | 3 | 4 | 5 | 6 | - [Standard 32-bit Roaring Bitmap](#standard-32-bit-roaring-bitmap) 7 | * [General layout](#general-layout) 8 | + [1. Cookie header](#1-cookie-header) 9 | + [2. Descriptive header](#2-descriptive-header) 10 | + [3. Offset header](#3-offset-header) 11 | + [4. Container storage](#4-container-storage) 12 | * [Testing](#testing) 13 | * [Reference implementations](#reference-implementations) 14 | * [Sample Java source code](#sample-java-source-code) 15 | * [Sample C source code](#sample-c-source-code) 16 | * [Unsigned integers in Java](#unsigned-integers-in-java) 17 | - [Extension for 64-bit implementations](#extension-for-64-bit-implementations) 18 | * [General layout](#general-layout-1) 19 | * [Unsigned longs in Java](#unsigned-longs-in-java) 20 | * [Alternative 64-bit implementations](#alternative-64-bit-implementations) 21 | 22 | 23 | # Standard 32-bit Roaring Bitmap 24 | 25 | 26 | Roaring bitmaps are used by several important systems: 27 | 28 | * [Apache Lucene](http://lucene.apache.org/core/) and derivative systems such as Solr and [Elastic](https://www.elastic.co/), 29 | * Metamarkets' [Druid](http://druid.io/), 30 | * [Apache Spark](http://spark.apache.org), 31 | * [Apache Hive](http://hive.apache.org), 32 | * [Apache Tez](http://tez.apache.org), 33 | * [Netflix Atlas](https://github.com/Netflix/atlas), 34 | * [LinkedIn Pinot](https://github.com/linkedin/pinot/wiki), 35 | * [OpenSearchServer](http://www.opensearchserver.com), 36 | * [Cloud Torrent](https://github.com/jpillora/cloud-torrent), 37 | * [Whoosh](https://pypi.python.org/pypi/Whoosh/), 38 | * [Pilosa](https://www.pilosa.com/), 39 | * [Jive Miru](https://github.com/jivesoftware/miru), 40 | * [Microsoft Visual Studio Team Services (VSTS)](https://www.visualstudio.com/team-services/), 41 | * eBay's [Apache Kylin](http://kylin.io). 42 | 43 | Many of these systems use the following interoperable format. 44 | 45 | This specification assumes that you are familiar with Roaring bitmaps. Please refer to the following paper for details on the design rationale: 46 | 47 | - Daniel Lemire, Gregory Ssi-Yan-Kai, Owen Kaser, [Consistently faster and smaller compressed bitmaps with Roaring](https://arxiv.org/abs/1603.06549), Software: Practice and Experience, Software: Practice and Experience Volume 46, Issue 11, pages 1547-1569, November 2016 48 | 49 | Let us recap that Roaring bitmaps are designed to store sets of 32-bit (unsigned) integers. Thus a Roaring bitmap can contain up to 4294967296 integers. They are made of three types of 16-bit containers: array, bitset and run containers. There are between 1 and 65536 (inclusively) containers. Each container has a cardinality (value in [1, 65536]), and it has a 16-bit most significant value (also called "key") in [0,65536). All containers are non-empty. 50 | 51 | ## General layout 52 | 53 | All words are written using little endian encoding. 54 | 55 | The layout is designed so that random access to the data is possible without materializing the bitmap in memory while being storage efficient. 56 | 57 | - There is an initial "cookie header" which allows us to recognize that the bit stream is a roaring bitmap and gather some minimal information; 58 | - The cookie header is followed by a "descriptive header" which describes the containers; 59 | - Depending on the cookie header, there is an offset header to allow fast random access to the stored containers; 60 | - The header is followed by the containers, serialized one by one. 61 | 62 | Throughout, we use the following constants : 63 | 64 | - SERIAL_COOKIE_NO_RUNCONTAINER = 12346, 65 | - SERIAL_COOKIE = 12347, 66 | - NO_OFFSET_THRESHOLD = 4 67 | 68 | The below diagram represents a storage file containing both run containers and the offset header. 69 | 70 | ![Format diagram](diagram.png) 71 | 72 | ### 1. Cookie header 73 | 74 | The cookie header spans either 64 bits or 32 bits followed by a variable number of bytes. 75 | 76 | 1. If the first 32 bits take the value SERIAL_COOKIE_NO_RUNCONTAINER, then no container part of the Roaring bitmap can be of type "run" (only array and bitset containers are allowed). When the cookie has this particular value, the next 32 bits are used to store an integer representing the number of containers. If the bitmap is empty (i.e., it has no container), then you should choose this cookie header. In this scenario, the cookie header uses 64 bits. 77 | 2. The 16 least significant bits of the 32-bit cookie have value SERIAL_COOKIE. In that case, the 16 most significant bits of the 32-bit cookie are used to store the number of containers minus 1. That is, if you shift right by 16 the cookie and add 1, you get the number of containers. Let ``size`` be the number of containers. Then we store ``(size + 7) / 8`` bytes, following the initial 32 bits, as a bitset to indicate whether each of the containers is a run container (bit set to 1) or not (bit set to 0). The first (least significant) bit of the first byte corresponds to the first stored container and so forth. In this scenario, the cookie header uses 32 bits followed by ``(size + 7) / 8`` bytes. 78 | 79 | Thus it follows that the least significant 16 bits of the first 32 bits of a serialized bitmaps should either have the value SERIAL_COOKIE_NO_RUNCONTAINER or the value SERIAL_COOKIE. In other cases, we should abort the decoding. 80 | 81 | After scanning the cookie header, we know how many containers are present in the bitmap. 82 | 83 | ### 2. Descriptive header 84 | 85 | The cookie header is followed by a descriptive header. For each container, we store 86 | the key (16 most significant bits) along with the cardinality minus 1, using 16 bits 87 | for each value (for a total of 32 bits per container). 88 | 89 | Thus, if there are x containers, the descriptive header will contain 32 x bits or 4 x bytes. 90 | 91 | After scanning the descriptive header, we know the type of each container. Indeed, 92 | if the cookie took value SERIAL_COOKIE, then we had a bitset telling us which containers 93 | are run containers; otherwise, we know that there are no run containers. For the containers 94 | that are not run containers, then we use the cardinality to determine the type: a 95 | cardinality of up and including 4096 indicates an array container whereas a cardinality above 96 | 4096 indicates a bitset container. 97 | 98 | ### 3. Offset header 99 | 100 | If and only if one of these is true 101 | 102 | 1. the cookie takes value SERIAL_COOKIE_NO_RUNCONTAINER 103 | 2. the cookie takes the value SERIAL_COOKIE *and* there are at least NO_OFFSET_THRESHOLD containers, 104 | 105 | then we store (using a 32-bit value) the location (in bytes) of the container from the beginning of the stream (starting 106 | with the cookie) for each container. 107 | 108 | ### 4. Container storage 109 | 110 | The containers are then stored one after the other. 111 | - For array containers, we store a sorted list of 16-bit unsigned integer values corresponding to the array container. So if there are x values in the array container, 2 x bytes are used. 112 | - Bitset containers are stored using exactly 8KB using a bitset serialized with 64-bit words. Thus, for example, if value j is present, then word j/64 (starting at word 0) will have its (j%64) least significant bit set to 1 (starting at bit 0). 113 | - A run container is serialized as a 16-bit integer indicating the number of runs, followed by a pair of 16-bit values for each run. Runs are non-overlapping and sorted. Thus a run container with x runs will use 2 + 4 x bytes. Each pair of 16-bit values contains the starting index of the run followed by the length of the run minus 1. That is, we interleave values and lengths, so that if you have the values 11,12,13,14,15, you store that as 11,4 where 4 means that beyond 11 itself, there are 4 contiguous values that follow. Other example: e.g., 1,10, 20,0, 31,2 would be a concise representation of 1, 2, ..., 11, 20, 31, 32, 33 114 | 115 | ## Testing 116 | 117 | At a minimum, all Roaring implementations should be able to parse the two files in the ``testdata`` directory, see the associated README.md file found in the directory. 118 | 119 | ## Reference implementations 120 | 121 | - C/C++: https://github.com/RoaringBitmap/CRoaring 122 | - Java: https://github.com/RoaringBitmap/RoaringBitmap 123 | - Go: https://github.com/RoaringBitmap/roaring 124 | 125 | 126 | ## Sample Java source code 127 | 128 | ```Java 129 | 130 | int startOffset = 0; 131 | boolean hasrun = hasRunContainer(); 132 | if (hasrun) { 133 | out.writeInt(Integer.reverseBytes(SERIAL_COOKIE | ((size - 1) << 16))); 134 | byte[] bitmapOfRunContainers = new byte[(size + 7) / 8]; 135 | for (int i = 0; i < size; ++i) { 136 | if (this.values[i] instanceof RunContainer) { 137 | bitmapOfRunContainers[i / 8] |= (1 << (i % 8)); 138 | } 139 | } 140 | out.write(bitmapOfRunContainers); 141 | if (this.size < NO_OFFSET_THRESHOLD) { 142 | startOffset = 4 + 4 * this.size + bitmapOfRunContainers.length; 143 | } else { 144 | startOffset = 4 + 8 * this.size + bitmapOfRunContainers.length; 145 | } 146 | } else { // backwards compatibility 147 | out.writeInt(Integer.reverseBytes(SERIAL_COOKIE_NO_RUNCONTAINER)); 148 | out.writeInt(Integer.reverseBytes(size)); 149 | startOffset = 4 + 4 + 4 * this.size + 4 * this.size; 150 | } 151 | for (int k = 0; k < size; ++k) { 152 | out.writeShort(Short.reverseBytes(this.keys[k])); 153 | out.writeShort(Short.reverseBytes((short) (this.values[k].getCardinality() - 1))); 154 | } 155 | if ((!hasrun) || (this.size >= NO_OFFSET_THRESHOLD)) { 156 | // writing the containers offsets 157 | for (int k = 0; k < this.size; k++) { 158 | out.writeInt(Integer.reverseBytes(startOffset)); 159 | startOffset = startOffset + this.values[k].getArraySizeInBytes(); 160 | } 161 | } 162 | for (int k = 0; k < size; ++k) { 163 | values[k].writeArray(out); 164 | } 165 | ``` 166 | ## Sample C source code 167 | ```C 168 | 169 | char *initbuf = buf; 170 | uint32_t startOffset = 0; 171 | bool hasrun = ra_has_run_container(ra); 172 | if (hasrun) { 173 | uint32_t cookie = SERIAL_COOKIE | ((ra->size - 1) << 16); 174 | memcpy(buf, &cookie, sizeof(cookie)); 175 | buf += sizeof(cookie); 176 | uint32_t s = (ra->size + 7) / 8; 177 | uint8_t *bitmapOfRunContainers = (uint8_t *)calloc(s, 1); 178 | assert(bitmapOfRunContainers != NULL); // todo: handle 179 | for (int32_t i = 0; i < ra->size; ++i) { 180 | if (get_container_type(ra->containers[i], ra->typecodes[i]) == 181 | RUN_CONTAINER_TYPE_CODE) { 182 | bitmapOfRunContainers[i / 8] |= (1 << (i % 8)); 183 | } 184 | } 185 | memcpy(buf, bitmapOfRunContainers, s); 186 | buf += s; 187 | free(bitmapOfRunContainers); 188 | if (ra->size < NO_OFFSET_THRESHOLD) { 189 | startOffset = 4 + 4 * ra->size + s; 190 | } else { 191 | startOffset = 4 + 8 * ra->size + s; 192 | } 193 | } else { // backwards compatibility 194 | uint32_t cookie = SERIAL_COOKIE_NO_RUNCONTAINER; 195 | 196 | memcpy(buf, &cookie, sizeof(cookie)); 197 | buf += sizeof(cookie); 198 | memcpy(buf, &ra->size, sizeof(ra->size)); 199 | buf += sizeof(ra->size); 200 | 201 | startOffset = 4 + 4 + 4 * ra->size + 4 * ra->size; 202 | } 203 | for (int32_t k = 0; k < ra->size; ++k) { 204 | memcpy(buf, &ra->keys[k], sizeof(ra->keys[k])); 205 | buf += sizeof(ra->keys[k]); 206 | 207 | uint16_t card = 208 | container_get_cardinality(ra->containers[k], ra->typecodes[k]) - 1; 209 | memcpy(buf, &card, sizeof(card)); 210 | buf += sizeof(card); 211 | } 212 | if ((!hasrun) || (ra->size >= NO_OFFSET_THRESHOLD)) { 213 | // writing the containers offsets 214 | for (int32_t k = 0; k < ra->size; k++) { 215 | memcpy(buf, &startOffset, sizeof(startOffset)); 216 | buf += sizeof(startOffset); 217 | startOffset = 218 | startOffset + 219 | container_size_in_bytes(ra->containers[k], ra->typecodes[k]); 220 | } 221 | } 222 | for (int32_t k = 0; k < ra->size; ++k) { 223 | buf += container_write(ra->containers[k], ra->typecodes[k], buf); 224 | } 225 | ``` 226 | 227 | ## Unsigned integers in Java 228 | 229 | Java lacks native unsigned integers, but integers are still considered to be unsigned within Roaring, and ordered according to  ``Integer.compareUnsigned``. 230 | 231 | For 32-bit integers in [0,2147483647], the unsigned and signed integers are undistinguisable since Java relies a 32-bit two's complement format for its ``int`` type. 232 | 233 | # Extension for 64-bit implementations 234 | 235 | Some Roaring bitmap implementations may offer a 64-bit implementation. This section proposes a portable format, compatible with some (but not all) 236 | 64-bit implementations. This format is naturally compatible with implementations based on a conventional red-black-tree (as the serialization format 237 | is similar to the in-memory layout). The keys would be 32-bit integers representing the most significant 32~bits of elements whereas the values of the 238 | tree are 32-bit Roaring bitmaps. The 32-bit Roaring bitmaps represent the least significant bits of a set of elements. 239 | 240 | ## General layout 241 | 242 | All words are written using little endian encoding. 243 | 244 | - Write as long/uint64 the distinct number of buckets (restricted to integers in [0,4294967295]) (a.k.a the number of distinct keys being the most significant 32~bits of elements, leading to a four zero bytes padding). 245 | - Iterate through buckets ordered by increasing keys (as unsigned integers), for each: 246 | - first writing as int/uint32 the most significant 32~bits of the bucket (in [0,2^32-1]) 247 | - second writing the 32-bit Roaring bitmaps representing the least significant bits of a set of elements 248 | 249 | ## Unsigned longs in Java 250 | 251 | Java lacks native unsigned longs, but longs are still considered to be unsigned within Roaring, and ordered according to ``Long.compareUnsigned``. 252 | 253 | For 64-bit integers in [0,18446744073709551616], the unsigned and signed longs are undistinguisable since Java relies a 64-bit two's complement format for its ``long`` type. 254 | 255 | ## Alternative 64-bit implementations 256 | 257 | Java Roaring bitmaps implementation offers an [ART-based 64-bit implementation](https://github.com/RoaringBitmap/RoaringBitmap/blob/master/RoaringBitmap/src/main/java/org/roaringbitmap/longlong/Roaring64Bitmap.java). 258 | It may reach better performances (compression and/or computation). But as of 2022-11, it is not compatible with this Serialization format. 259 | 260 | Java Roaring bitmaps implementation offers an [``Map``-based 64-bit implementation](https://github.com/RoaringBitmap/RoaringBitmap/blob/master/RoaringBitmap/src/main/java/org/roaringbitmap/longlong/Roaring64NavigableMap.java) handling signed longs. 261 | It is not compatible with this serialization format (which does not handle signed keys). 262 | 263 | # Kaitai Struct Definitions 264 | 265 | See [roaringbitmap.ksy](roaringbitmap.ksy)/[roaringbitmap64.ksy](roaringbitmap64.ksy) for the [Kaitai Struct] 266 | definitions of the Roaring bitmap format for 32-bit and 64-bit implementations respectively. 267 | 268 | [Kaitai Struct]: https://kaitai.io/ 269 | -------------------------------------------------------------------------------- /diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/RoaringBitmap/RoaringFormatSpec/883e28c3499aa025acf61593f982bcade38066ad/diagram.png -------------------------------------------------------------------------------- /roaringbitmap.ksy: -------------------------------------------------------------------------------- 1 | doc: | 2 | Roaring bitmaps are compressed bitmaps which tend to outperform 3 | conventional compressed bitmaps such as WAH, EWAH or Concise. 4 | 5 | They are used by several important systems: 6 | 7 | * Apache Lucene and derivative systems such as Solr and Elastic 8 | * Metamarkets' Druid 9 | * Apache Spark 10 | * Apache Hive 11 | * Apache Tez 12 | * Netflix Atlas 13 | * LinkedIn Pinot 14 | * and many others 15 | 16 | Roaring bitmaps are designed to store sets of 32-bit unsigned integers efficiently. 17 | They use a two-level structure: the 32-bit integers are split into 18 | 16-bit "chunks" (most significant bits + least significant bits). 19 | Each chunk is stored in a container, of which there are three types: 20 | array, bitset, and run containers. 21 | 22 | meta: 23 | id: roaringbitmap 24 | title: Roaring Bitmap Portable Format 25 | license: Apache-2.0 26 | endian: le 27 | 28 | seq: 29 | - id: magic 30 | type: u2 31 | enum: cookie 32 | doc: | 33 | Magic cookie value that identifies the type of Roaring Bitmap format. 34 | 12346 (SERIAL_COOKIE_NO_RUNCONTAINER) means no run containers are used. 35 | 12347 (SERIAL_COOKIE) means run containers may be present. 36 | 37 | - id: header 38 | type: 39 | switch-on: magic 40 | cases: 41 | 'cookie::no_runs': header_no_runs 42 | 'cookie::with_runs': header_with_runs 43 | doc: | 44 | Header structure that follows the magic cookie value. 45 | The structure differs depending on whether run containers are used or not. 46 | 47 | - id: container_meta 48 | type: container_meta 49 | repeat: expr 50 | repeat-expr: num_containers 51 | doc: | 52 | Descriptive header containing the key (16 most significant bits) and 53 | cardinality of each container. 54 | 55 | - id: offset_header 56 | if: (not has_runs) or (num_containers >= 4) 57 | type: u4 58 | repeat: expr 59 | repeat-expr: num_containers 60 | doc: | 61 | Offset header containing the byte offsets of each container from the beginning 62 | of the stream. This is included if either: 63 | 1. No run containers are present, or 64 | 2. There are at least NO_OFFSET_THRESHOLD (4) containers 65 | 66 | - id: containers 67 | type: 68 | switch-on: > 69 | ( 70 | has_runs 71 | ? ( 72 | header.as.run_bitset[_index / 8] & (1 << (_index % 8)) 73 | ) != 0 74 | : false 75 | ) 76 | ? 1 77 | : container_meta[_index].cardinality_minus_1 + 1 <= 4096 ? 2 : 3 78 | cases: 79 | 1: run_container 80 | 2: array_container(container_meta[_index].cardinality_minus_1 + 1) 81 | 3: bitset_container 82 | repeat: expr 83 | repeat-expr: num_containers 84 | doc: | 85 | The actual container data. The type is determined by: 86 | - If run containers are allowed and the run_bitset indicates this container is a run container, use run_container (type 1) 87 | - Otherwise, if the container's cardinality is <= 4096, use array_container (type 2) 88 | - Otherwise, use bitset_container (type 3) 89 | 90 | instances: 91 | has_runs: 92 | value: magic == cookie::with_runs 93 | doc: | 94 | Computed field that indicates whether this Roaring bitmap may contain run containers. 95 | 96 | num_containers: 97 | value: > 98 | has_runs ? (header.as.num_containers_minus_1 + 1) : header.as.num_containers 99 | doc: | 100 | Computed field that returns the number of containers in the bitmap. 101 | For backwards compatibility, the encoding differs depending on whether run containers are present. 102 | 103 | types: 104 | header_no_runs: 105 | doc: | 106 | Header format for bitmaps that don't use run containers. 107 | This contains a 32-bit value (SERIAL_COOKIE_NO_RUNCONTAINER) 108 | followed by 32 bits for the number of containers. 109 | seq: 110 | - contents: [0, 0] 111 | doc: Two zeros to complete the 32-bit cookie (after the initial 16-bit magic) 112 | - id: num_containers 113 | type: u4 114 | doc: Number of containers in this bitmap 115 | 116 | header_with_runs: 117 | doc: | 118 | Header format for bitmaps that may use run containers. 119 | The 16-bit cookie's most significant bits store the number of containers minus 1. 120 | A run container bitset follows, with a 1 bit indicating the container is a run container. 121 | seq: 122 | - id: num_containers_minus_1 123 | type: u2 124 | doc: Number of containers minus 1 (to allow encoding 65536 containers) 125 | - id: run_bitset 126 | size: (num_containers_minus_1 + 1 + 7) / 8 127 | doc: | 128 | Bitset indicating which containers are run containers (1 bit) vs array/bitset (0 bit). 129 | The least significant bit of the first byte corresponds to the first container. 130 | 131 | container_meta: 132 | doc: | 133 | Metadata for a single container, consisting of its key (16 most significant bits) 134 | and its cardinality minus 1 (to allow encoding full 65536 cardinality). 135 | seq: 136 | - id: key 137 | type: u2 138 | doc: Container key (16 most significant bits of the integers in this container) 139 | - id: cardinality_minus_1 140 | type: u2 141 | doc: | 142 | Container cardinality minus 1. This is used to determine whether a 143 | container is an array container (cardinality <= 4096) or a bitset container. 144 | 145 | run_container: 146 | doc: | 147 | Run container format, storing sorted runs of consecutive integers. 148 | More space-efficient for data with long consecutive runs of values. 149 | Runs are non-overlapping and sorted. 150 | seq: 151 | - id: num_runs 152 | type: u2 153 | doc: Number of runs in this container 154 | - id: runs 155 | type: run 156 | repeat: expr 157 | repeat-expr: num_runs 158 | doc: Array of runs (start value and length pairs) 159 | 160 | run: 161 | doc: | 162 | A run of consecutive integers, represented by a starting value and a length. 163 | seq: 164 | - id: start_idx 165 | type: u2 166 | doc: Starting value of the run 167 | - id: count_minus_1 168 | type: u2 169 | doc: | 170 | Length of the run minus 1. For example, a run of [11,12,13,14,15] 171 | would be encoded as start_idx=11, count_minus_1=4. 172 | 173 | array_container: 174 | doc: | 175 | Array container storing a sorted array of 16-bit integers. 176 | Used when the container has relatively few values (cardinality <= 4096). 177 | params: 178 | - id: num_values 179 | type: u2 180 | doc: Number of values in this array container 181 | seq: 182 | - id: values 183 | type: u2 184 | repeat: expr 185 | repeat-expr: num_values 186 | doc: Sorted array of 16-bit values in this container 187 | 188 | bitset_container: 189 | doc: | 190 | Bitset container using a 65536-bit bitset (8KB) to represent which 191 | values are present. Used when the container has many values (cardinality > 4096). 192 | seq: 193 | - id: bitset 194 | size: 8 * 1024 195 | doc: | 196 | A dense 8KB bitset (2^16 bits). 197 | 198 | enums: 199 | cookie: 200 | 12346: no_runs 201 | 12347: with_runs 202 | -------------------------------------------------------------------------------- /roaringbitmap64.ksy: -------------------------------------------------------------------------------- 1 | doc: | 2 | Some Roaring bitmap implementations may offer a 64-bit implementation. This section proposes a portable format, 3 | compatible with some (but not all) 64-bit implementations. This format is naturally compatible with implementations 4 | based on a conventional red-black-tree (as the serialization format is similar to the in-memory layout). The keys 5 | would be 32-bit integers representing the most significant 32~bits of elements whereas the values of the tree are 6 | 32-bit Roaring bitmaps. The 32-bit Roaring bitmaps represent the least significant bits of a set of elements. 7 | 8 | meta: 9 | id: roaringbitmap64 10 | title: Roaring Bitmap Portable 64 Bit Format 11 | license: Apache-2.0 12 | endian: le 13 | imports: 14 | - roaring_bitmap_32bit 15 | 16 | 17 | seq: 18 | - id: num_buckets 19 | type: u8 20 | doc: The number of sub-buckets (32 bit roaring bitmaps). 21 | - id: buckets 22 | type: bucket 23 | repeat: expr 24 | repeat-expr: num_buckets 25 | 26 | types: 27 | bucket: 28 | doc: For each sub-bucket, the upper 32 bits of the bucket, and a 32 bit roaring bitmap. 29 | seq: 30 | - id: key 31 | type: u4 32 | doc: The upper 32 bits of the bucket. 33 | - id: bitmap 34 | type: roaringbitmap 35 | 36 | -------------------------------------------------------------------------------- /testdata/README.md: -------------------------------------------------------------------------------- 1 | # test data 2 | 3 | These bitmaps were generated from Java : 4 | https://github.com/RoaringBitmap/RoaringBitmap/blob/master/examples/SerializeToDiskExample.java 5 | 6 | They were created by adding the following values: 7 | 8 | ```Java 9 | for (int k = 0; k < 100000; k+= 1000) { 10 | rb.add(k); 11 | } 12 | for (int k = 100000; k < 200000; ++k) { 13 | rb.add(3*k); 14 | } 15 | for (int k = 700000; k < 800000; ++k) { 16 | rb.add(k); 17 | } 18 | ``` 19 | 20 | That is, they contain all multiplies of 1000 in [0,100000), all multiplies of 3 in [100000,200000) and all values in [700000,800000). 21 | 22 | There are two files: 23 | - bitmapwithoutruns.bin is the result of a serialization without run containers; 24 | - bitmapwithruns.bin is the result of a serialization with run containers. 25 | 26 | 27 | 28 | -------------------------------------------------------------------------------- /testdata/bitmapwithoutruns.bin: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/RoaringBitmap/RoaringFormatSpec/883e28c3499aa025acf61593f982bcade38066ad/testdata/bitmapwithoutruns.bin -------------------------------------------------------------------------------- /testdata/bitmapwithruns.bin: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/RoaringBitmap/RoaringFormatSpec/883e28c3499aa025acf61593f982bcade38066ad/testdata/bitmapwithruns.bin --------------------------------------------------------------------------------