{'fraction_non_alphanumeric': 0.028032746216819646, 'fraction_numerical': 0.005953857603572314, 'mean_word_length': 5.203076923076923, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
C Component-based Generalized Database Index Model

The performance of a database is greatly affected by the performance of its indexes. An industrial quality database typically has several indexes associated with it. Therefore, the design of a good quality index is essential to the success of any nontrivial database. Parallel to their significance, indexed data structures are inherently complex applications that require a lot of effort and consume a considerable amount of resources. Index frameworks rely on code reuse to reasonably reduce the costs associated with them (Lynch & Stonebraker, 1988; Stonebraker, 1986). Generalized database systems have further addressed this challenge by offering databases with indexes that can be adjusted to different data/key types, different queries, or both. The generalized search tree (GiST; Hellerstein, Naughton, & Pfeffer, 1995; Hellerstein, Papadimitriou, & Koutsoupias, 1997) is a good example of a database system with a generalized index, or generalized index database for simplicity. Additional improvements extended the concept of generalized index databases to work on different domains by having generalized access methods (search criteria). For example, based on the work of Hellerstein et al. (1995), Aoki (1998) provides a generalized framework that allows users to adjust the index to different search criteria like equality, similarity, or nearest neighbor search. This makes the database system customizable to not only finding the exact records, but also to finding records that are “similar” or “close” to a given record. Users can customize their own criteria of “similarity” and let the index apply it to the database and return all “similar” results. This is particularly important for more challenging domains like multimedia applications, where there is always the need to find a “close image,” a “similar sound,” or “matching fingerprints.” The common drawback of all these improvements is having a monolithic code that allows users to only adjust the few lines of code that are meant to be customized. Outside these areas, code is often bulky and difficult to maintain or upgrade. However, with the increasing dependence on software engineering techniques, these problems can be ratified. Component-based frameworks provide solid ground for future maintenance, replacement, and additions to the code in an orderly fashion that does not reduce the quality of the system (the aging effect). Customization does not have to be limited to few lines of the code. In our work, we provide a new model to redesign the generalization of database indexes using components. Unlike previous works, the customization is not done at the code level, but rather at higher conceptual levels from the early design stages. Our design is based on total decoupling of the design modules and connecting them through well-defined interfaces to build the database system. All this is done at the design level. After the design is completed, implementation is done by obtaining the already-existing commercial off the-shelf (COTS) components and connecting them together according to the design model. Following this design-level customization paradigm, the system can be customized as usual by the user at prespecified locations (predefined few lines of code), but more importantly, a large-scale customization is also possible at the design level. The system designer can redesign the generalized model by adding, removing, or replacing a few components in the design model to instantiate the model into a new concrete design. Afterwards, only the affected components of the source code need to be replaced by new ones. In our system, COTS components are extensively used, which dramatically reduces the cost of development. We needed to implement a few components with the same predefined interfaces where COTS components were not suitable, for example, when special concurrency control management or specific storage needs were necessary. This adds more flexibility to the model.