Bitrix Framework

Description

In contrast to Information blocks module, Highload blocks module can store each entity in their own individual tables, without associating with any module. Entity fields are core's user properties. It is necessary to differentiate User fields in system modules and properties used within information blocks, although system forms (forms for creating/editing an iblock section and others) use a "user property" term

Entities are generated in admin interface, without additional programming.

Access to data is provided based on ORM.

Data allocation can be performed both to a single database and to different databases in general. This way a project's scaling out becomes possible, when some objects are located at one server, and some data - on another.

The Highload blocks module supports NoSQL concept based on MySQL database. Database connection is provided with both handlersocket extension for MySQL, as well as without it. Handlersocket use requires additional settings.

For example, when project supports NoSQL, with all required installed drivers for MySQL and core/kernel configuration had been established connection via these drivers. As result, Highload blocks module allows creating entities and building project in a manner that data retrieval from database was performed via the driver by primary key.

The following actions must be performed to use ORM entity for Highload blocks:

• Initialize entity in the system:

  //first, select entity data from the database
  $hldata = Bitrix\Highloadblock\HighloadBlockTable::getById($ID)->fetch();
  
  //then initialize entity class
  $hlentity = Bitrix\Highloadblock\HighloadBlockTable::compileEntity($hldata);
  

• Next, creates queries with this entity:

  $query = new Entity\Query($hlentity);
  

  or use via DataManager interface:

  $hlDataClass = $hldata['NAME'].'Table';
  $hlDataClass::getList();
  

All further handling of Highload blocks is governed by the ORM rules, because entity, created in the Highload blocks is an ORM entity.

Module contains two components: list of entity records (highloadblock.list) and entity detail view (highloadblock.view).

List association

Association of directory to Highload block is performed via the USER_TYPE_SETTINGS properties. They contain table name.

Association of property values uses UF_XML_ID (completing the field is required), otherwise element's "list" property values are not saved.

Highloadblock and handlersocket

Traditional ACID Databases generally complicate project implementation for specific tasks. Such frameworks as NoSQL and HandlerSocket were designed for such tasks (in a form of plugin to standard MySQL).

HandlerSocket allows customer application to connect directly to MySQL data engine to reduce excessive load, specific to traditional queries via the SQL interface and unacceptable to highly loaded databases.

Example comparison for number of queries, permitted by different database handling methods:

The difference between querying via MySQL client and via HandlerSocket is that in the second case, parsing, table openings, execution schedule optimization are skipped. It means that querying is performed directly and the load to MySQL decreases significantly. Queries are not executed quicker, but reduces server load.

Connecting HandlerSocket is specified in the file Core parameter settings.

You can install the plugin either by directly downloading MySQL source files and assembling the plugin, or by installing PerconaServer or MariaDB, with plugin enabled by default.

HS API is called when querying the Highloadblock ($obj = $entityClass::getById( $arData["ID"] )->fetch();) via HandlerSocket (query open_index and find in MySQL) with call result processing by the application.

HandlerSocket launches a thread pool inside the database, operating in asynchronous mode. (NGINX operates in a similar manner) In standard cases MySQL operates with a single thread for each client connection (thread) and works inside it. However, in case of HandlerSocket, it uses a pool of threads with multiplex system pool/select calls. That's why, for example, 5 threads can process hundreds of thousands queries.

Highload blocks handling examples

<?
//Preparation:
if (CModule::IncludeModule('highloadblock')) {
   $arHLBlock = Bitrix\Highloadblock\HighloadBlockTable::getById(1)->fetch();
   $obEntity = Bitrix\Highloadblock\HighloadBlockTable::compileEntity($arHLBlock);
   $strEntityDataClass = $obEntity->getDataClass();
}

//Adding:
if (CModule::IncludeModule('highloadblock')) {
   $arElementFields = array(
      'UF_NAME' => $arPost['name'],
      'UF_MESSAGE' => $arPost['message'],
      'UF_DATETIME' => new \Bitrix\Main\Type\DateTime
   );
   $obResult = $strEntityDataClass::add($arElementFields);
   $ID = $obResult->getID();
   $bSuccess = $obResult->isSuccess();
}

//Retrieving the list:
if (CModule::IncludeModule('highloadblock')) {
   $rsData = $strEntityDataClass::getList(array(
      'select' => array('ID','UF_NAME','UF_MESSAGE','UF_DATETIME'),
      'order' => array('ID' => 'ASC'),
      'limit' => '50',
   ));
   while ($arItem = $rsData->Fetch()) {
      $arItems[] = $arItem;
   }
}
?>

Arbitrary value selection:

$q = new Entity\Query($entity);
       $q->setSelect(array('*'));
       $q->setFilter($arFilter);
       $q->setLimit(1);
       $q->registerRuntimeField(
           'RAND', array('data_type' => 'float', 'expression' => array('RAND()'))
       );
       $q->addOrder("RAND", "ASC");
       $result = $q->exec();