For example, we might have a generic version of a special effect added into a scene at the sequence level:. Now, at the shot-level, we have a shotFX. usd layer that participates in the same LayerStack as sequenceFX. usd because one of the shot layers SubLayers in the sequence.

usd layer, which in turn SubLayers the above sequenceFX. usd layer. In this particular shot, we need to replace the generic turbulence effect with a different one, which may have completely different prims in it. usd, but not turbulence. In this second example we have also shown that the operand of list-editing operations can be a list that can contain multiple targets.

List editing is a feature to which some array-valued data elements in USD can subscribe, that allows the array-type element to be non-destructively, sparsely modified across composition arcs. It would be very expensive and difficult to reason about list editable elements that are also time-varying, so Attributes can never be list editable. When an element is list editable, instead of only being able to assign an explicit value to it, you can also, in any stronger layer:.

append another value or values to the back of the resolved list; if the values already appear in the resolved list, they will be reshuffled to the back. delete a value or values from the resolved list. prepend another value or values on the front of the resolved list; if the values already appear in the resolved list, they will be shuffled to the front. A prepended composition arc in a weaker layer of a LayerStack will still be stronger than any arcs of the same type that are appended from stronger layers.

This causes the resolved list to be reset to the provided value or values, ignoring all list ops from weaker layers. Also, in the usda text syntax, any operation can assign either a single value without the square-bracket list delimiters, or a sequence of values inside square brackets.

See LayerStack for an example of list editing, as applied to references. See also the FAQ on deleting items with list ops: When can you delete a reference or other deletable thing? LIVRPS is an acronym for Local, Inherits, VariantSets, References, Payload, Specializes , and is the fundamental rubric for understanding how opinions and namespace compose in USD.

LIVRPS describes the strength ordering in which the various composition arcs combine, within each LayerStack. Iterate through all the layers in the local LayerStack looking for opinions on the PrimSpec at path in each layer - recall that according to the definition of LayerStack, this is where the effect of direct opinions in all SubLayers of the root layer of the LayerStack will be consulted.

If no opinion is found, then…. Resolve the Inherits affecting the prim at path , and iterate through the resulting targets. Apply the resolved variant selections to all VariantSets that affect the PrimSpec at path in the LayerStack, and iterate through the selected Variants on each VariantSet. Resolve the References affecting the prim at path , and iterate through the resulting targets.

Resolve the Payload arcs affecting the prim at path ; if path has been loaded on the stage, iterate through the resulting targets just as we would references from step 4. It may sound like a great deal of work to need to perform for every value lookup, and it absolutely would be if we followed all the steps as described above, during value resolution.

The algorithm for computing the namespace of the stage i. what prims are present and where are slightly more involved, but still follows the LIVRPS recipe. Wherever a Stage contains at least one Payload payloads can be list-edited and chained , the client has the ability to Load compose all the scene description targeted by the Payload, or to Unload the Payloads and all their scene description, recomposing all prims beneath the payloaded-prim, recursively unloading their payloads, should they possess any.

For more information, see Working Set Management in the USD Manual. USD allows the construction of highly referenced and layered scenes that assemble files from many different sources, which may resolve differently in different contexts for example, your asset resolver may apply external state to select between multiple versions of an asset.

UsdUtilsCreateNewUsdzPackage does this for you, although we have not yet exposed the ability to just localize yet, but we hope to eventually. Metadata are extensible, however adding a new, named piece of metadata requires a change to a configuration file to do so, because the software wants to know, definitively, what the datatype of the metadatum should be. USD provides a special, dictionary-valued metadatum called customData that provides a place to put user metadata without needing to touch any configuration files.

For more information on the allowed types for metadata and how to add new metadata to the system, please see the discussion of metadata in the API manual. Model is a scenegraph annotation ascribable to prims by setting their kind metadata. See also Model Hierarchy. The model hierarchy defines a contiguous set of prims descending from a root prim on a stage, all of which are models. Model hierarchy is an index of the scene that is, strictly, a prefix , of the entire scene. The member prims must adhere to the following three rules:.

Only group model prims can have other model children assembly is a kind of group. A prim can only be a model if its parent prim is also a group model - except for the root model prim.

This implies that component models cannot have model children. Reasoning about referencing structure can get complicated very quickly and necessitate introducing fragile conventions. Namespace is simply the term USD uses to describe the set of prim paths that provide the identities for prims on a Stage , or PrimSpecs in a Layer. Opinions are the atomic elements that participate in Value Resolution in USD. Each time you author a value for a Metadatum, Attribute, or Relationship, you are expressing an opinion for that object in a PrimSpec in a particular Layer.

On a composed Stage, any object may be affected by multiple opinions from different layers; the ordering of these opinions is determined by the LIVRPS strength ordering. Over is one of the three possible specifiers a prim and also a PrimSpec can possess. When an application exports sparse overrides into a layer that sits on top of an existing composition, it is common to see deep nesting of overs. A path is a location in namespace. In USD text syntax and documentation , paths are enclosed in angle-brackets, as found in the authored targets for references , payloads , inherits , specializes , and relationships.

USD assigns paths to all elements of scene description other than metadata, and the concrete embodiment of a path, SdfPath , serves in the API as a compact, thread-safe, key by which to fetch and store scene description, both within a Layer, and composed on a Stage. The SdfPath syntax allows for recording paths to different kinds of scene description. For example:. visibility names the property visibility on the prim Grandchild.

Path translation is applied during such queries as finding a prim and fetching the targets of a relationship or connection , and inverse path translation is performed by the active Edit Target whenever you author to a stage.

usd into a shot. gprims , we will get back:. Deleting the target in shot. usd might look like this:. We mentioned above that path translation also operates in the opposite direction when you use Edit Targets to send your relationship or connection edits across a composition arc, because it follows that every encoded path must be in the namespace of the PrimSpec on which it is recorded.

For example, if we were working with the same shot. usd that looks like:. A Payload is a composition arc that is a special kind of a Reference. It is different from references primarily in two ways:. The targets of References are always consumed greedily by the indexing algorithm that is used to open and build a Stage. When a Stage is opened with UsdStage::InitialLoadSet::LoadNone specified, Payload arcs are recorded, but not traversed.

Payloads are weaker than references , so, for a particular prim within any given LayerStack , all direct references will be stronger than all direct payloads. See the performance note on packaging assets with payloads. Prims, along with their associated, computed indices , are the only persistent scenegraph objects that a Stage retains in memory, and the API for interacting with prims is provided by the UsdPrim class.

A prim definition is the set of built-in properties and metadata that a prim gains from a combination of the IsA schema determined from its typeName and its applied API schemas. The API for prim definitions are provided by the UsdPrimDefinition class. Each composed Prim on a Stage is the result of potentially many PrimSpecs each contributing their own scene description to a composite result. Similarly to a composed prim, a PrimSpec is a container for property data and nested PrimSpecs.

Importantly, composition arcs can only be applied on PrimSpecs, and those arcs that specify targets are targeting other PrimSpecs. In USD, you create and retrieve primvars using the UsdGeomImageable schema, and interact with the special primvar encoding using the UsdGeomPrimvar schema. Primvars define a value that can vary across the primitive on which they are defined, via prescribed interpolation rules.

Different renderers may communicate the variables to the shaders using different mechanisms over which Usd has no control; Primvars simply provide the classification that any renderer should use to locate potential overrides. Properties are the other kind of namespace object in USD Prims being the first. There are two types of Property: Attribute and Relationship.

All properties can be ordered within their containing Prim and are otherwise enumerated in dictionary order via UsdPrim::SetPropertyOrder , and can host Metadata. Here are some examples of namespaced properties from usd schemas:.

Just as PrimSpecs contain data for a prim within a layer, PropertySpecs contain the data for a property within a layer. A PropertyStack is a list of PropertySpecs that contribute a default or timeSample for Attributes or target for relationships , or any piece of metadata , for a given property. A PropertyStack does not contain the proper time-offsets that must be applied to the PrimSpecs to retrieve the correct timeSample when there are authored Layer Offsets on references , subLayers , or clips.

If your goal is to optimize repeated value resolutions on attributes, retain a UsdAttributeQuery instead, which is designed for exactly this purpose. Proxy is a highly overloaded term in computer graphics… but so were all the alternatives we considered for the same concept in USD. The idea behind this pairing is that the proxy provides a set of gprims that are lightweight to read and draw, and provide an idea of what the full render geometry will look like, at much cheaper cost.

The answer is twofold:. Most clients of USD in our pipeline place a high value on bringing up a complex scene for inspection and introspection as quickly as possible. It is a fairly lightweight operation to instruct the renderer to ignore the proxies and image the full render geometry, when that is required.

See Namespace for further details. Purpose is a builtin attribute of the UsdGeomImageable schema, and is a concept we have found useful in our pipeline for classifying geometry into categories that can each be independently included or excluded from traversals of prims on a stage, such as rendering or bounding-box computation traversals. For a discussion of the motivation for purpose , see Proxy. After SubLayers , References are the next most-basic and most-important composition arc. Because a PrimSpec can apply an entire list of References, References can be used to achieve a similar kind of layering of data, when one knows exactly which prims need to be layered and with some differences in how the participating opinions will be resolved.

Following is a simple example of referencing, with overrides. We start with a trivial model asset, Marble. Note that, for brevity, we are eliding some of the key data usually found in published assets such as AssetInfo , shading of any kind, Inherits , a Payload , detailed model substructure.

Now we want to create a collection of marbles, by referencing the Marble asset multiple times, and overriding some of the referenced properties to make each instance unique.

In the composed namespace, the prim name Marble is gone, since the references allowed us to perform a prim name-change on the prim targeted by the reference.

This is a key feature of references, since without it, we would be unable to reference the same asset more than once within any given prim scoping, because sibling prims must be uniquely named to form a proper namespace.

usd , the file Marble. usd was only opened once and shared by both references. For deeper sharing of referenced assets, in which the prims themselves are also shared, see Instancing. References can apply a Layer Offset to offset and scale the time-varying data contained in the referenced layer s. References can target any prim in a LayerStack , excepting ancestors of the prim containing the reference, if the reference is an internal reference targeting the same LayerStack in which the reference is authored.

When targeting sub-root prims, however, there is the potential for surprising behavior unless you are aware of and understand the ramifications. One such ramification is that if the targeted sub-root prim has an ancestor prim that contains a VariantSet , the referencer will have no ability to express a selection for that VariantSet. For a more complete discussion of the ramifications of referencing sub-root prims, see the UsdReferences class documentation.

See List Editing for the rules by which references can be combined within a LayerStack. Relationships can have multiple targets, as, for instance, the relationships in a UsdCollectionAPI target all of the objects that belong to the named collection; therefore, relationships are List Edited.

Now, because each marble in the MarbleCollection. usd scene has its own copy of the GlassMaterial prim, we expect that when we:. as the result, even though that was not the authored value in Marble.

The prims declared in root layers are the only ones locatable using the same paths that identify composed prims on the Stage. Currently, an Edit Target can only target PrimSpecs in the root LayerStack, although we hope to relax that restriction eventually. It is the layers of the root LayerStack that are the most useful in facilitating shared workflows using USD. USD defines a schema as an object whose purpose is to author and retrieve structured data from some UsdObject.

Schemas are lightweight objects we create to wrap a UsdObject , as and when needed, to robustly interrogate and author scene description. Specializes is a composition arc that allows a specialized prim to be continuously refined from a base prim, through unlimited levels of referencing.

A specialized prim will contain all of the scene description contained in the base prim it specializes including the entire namespace hierarchy rooted at the base prim , but any opinion expressed directly on the specialized prim will always be stronger than any opinion expressed on the base prim, in any referencing context.

Let us examine an example inspired by the first uses of the specializes arc at Pixar: specializing materials in our shading schema. For brevity, we focus on one particular specialization, a corroded metal; we also leave out many of the schema details of how materials and their shaders interact.

The above example is not realistic at all regarding how you would actually design a Metal or CorrodedMetal material! Specializes can target any prim on the stage that is neither an ancestor nor descendant of the specializing prim. In the example above, replacing the specializes with inherits will produce the same composed result - try it! In the sameRobot. The unique behavior of specializes only becomes evident, however, in a referencing context, so let us try one.

If you examine the flattened RobotScene. This also demonstrates the difference between specializes and inherits : if you change the specializes arc to inherits in Robot. The specializes behavior is desirable in this context of building up many unique refinements of something whose base properties we may want to continue to update as assets travel down the pipeline, but without changing anything that makes the refinements unique.

What if we do want to broadcast an edit on the Metal material to all of the Materials that specialize it? class - prims from which other prims inherit. The most common, default traversals, which are meant to be used for rendering and other common scenegraph processing, will visit only defined , non-abstract prims. A stage always presents the composed view of the scene description that backs it.

Mutated stage layers can be collectively saved to backing-store using UsdStage::Save. Most consumption of USD data follows the pattern of traversing an open stage, processing prims one at a time, or several in parallel. Given a UsdPrim p , one can fetch its direct children on the Stage using p.

One can also fetch a UsdPrimSubtreeRange directly from a prim via p. Additionally, and more commonly used in USD core code, one can traverse the subtree rooted at a prim by creating a UsdPrimRange , which allows for depth-first iteration with the ability to prune subtrees at any point during the iteration. Some examples are whether a prim is defined, or active, or loaded, etc. For a full list of the possible prim flags and examples of how they can be logically combined, see prim predicate flags.

The remaining methods e. GetChildren all use a predefined Default Predicate that serves a common traversal pattern. An exporter may choose to identify articulation points in a complicated model by labeling such prims as subcomponents for example, the DoorAssembly Xform inside an architectural model.

SubLayers is the composition arc used to construct LayerStacks. As an example, here is one possible combination of USD layers that could have been the source for the example in the LayerStack entry, and also demonstrate how SubLayers supports nested LayerStacks:.

Note that SubLayers can specify Layer Offsets to offset and scale time-varying data contained in the sub-layer s. TimeCodes are the unit-less time ordinate in USD. TimeSamples as source for Value Resolution. USD API sometimes refers to just the ordinate of a time-varying value as a TimeSample; for example, UsdAttribute::GetTimeSamples and UsdAttribute::GetTimeSamplesInInterval return a simple vector of time ordinates at which samples may be resolved on the attribute.

We plan to create a UsdUserPropertiesAPI schema to aid in authoring and enumerating user properties, but creating a property in the userProperties: namespace using UsdPrim::CreateAttribute not all importers may handle custom relationships properly is sufficient. Value Clips are a feature that allows one to partition varying attribute timeSample overrides into multiple files, and combine them in a manner similar to how non-linear video editing tools allow one to combine video clips.

Clips are especially useful for solving two important problems in computer graphics production pipelines:. Crowd animators will often create animation clips that can apply to many background characters, and be sequenced and cycled to generate a large variety of animation.

USD clips provide the ability to encode the sequencing and non-uniform time-mapping of baked animation clips that this task requires. USD Clips make it possible to stitch all of these files together into a continuous even though the data may itself be topologically varying over time animation, without needing to move, merge, or perturb the files that the simulator produced. The USD toolset includes a utility usdstitchclips that efficiently assembles a sequence of file-per-frame layers into a Value Clips representation.

The key advantage of the clips feature is that the resulting resolved animation on a UsdStage is indistinguishable from data collected or aggregated into a single layer.

In other words, consuming clients can be completely unaware of the existence of clips: there is no special schema or API required to access the data. The disadvantages of using clips are:. Encoding clips on a stage is more complicated than simply recording samples on attributes, or adding references see UsdClipsAPI for details on encoding.

For more information on value clip behavior and how clips are encoded, see Sequenceable, Re-timeable Animated Value Clips in the USD Manual.

Even though value resolution is the act of composing potentially many pieces of data together to produce a single value, we distinguish value resolution from composition because understanding the differences between the two aids in effective construction and use of USD:.

The USD core does not, however, pre-compute or cache any per-composed-property information, which is a principal design decision aimed at keeping latency low for random-access to composed data, and keeping the minimal memory footprint for USD low. Instead, for attribute value resolution, the USD core provides opt-in facilities such as UsdAttributeQuery and UsdResolveInfo , objects a client can construct and retain themselves that cache information that can make repeated value queries faster.

Composition is internally multi-threaded, value resolution is meant to be client multi-threaded. Composition of a large stage can be a big computation, and USD strives to effectively, internally multi-thread the computation; therefore clients should realize they are unlikely to gain performance from opening multiple stages simultaneously in different threads.

Composition rules vary by composition arc, value resolution rules vary by metadatum. Value resolution simply consumes the ordered strong-to-weak list of contributing sites, and is otherwise insensitive to the particular set of composition arcs that produced that list; but how the data in those sites is combined depends on the particular metadatum being resolved.

The basic rule for the metadata value resolution provided by UsdObject::GetMetadata is: strongest opinion wins. Certain metadata such as prim specifier , attribute typeName, and several others have special resolution rules; the only one we will discuss here is dictionary-valued metadata , because it is user-facing, as, for example, the customData dictionary authorable on any prim or property.

The rules for how the opinions combine in weak-to-strong order are contained inside SdfListOp::ApplyOperations. Warning This feature won't apply to commands like KEYS and SCAN that take patterns rather than actual keys , and this feature also won't apply to the replies of commands even if they are key names Most Redis commands take one or more Strings as arguments, and replies are sent back as a single String or an Array of Strings.

However, sometimes you may want something different. For instance, it would be more convenient if the HGETALL command returns a hash e. ioredis has a flexible system for transforming arguments and replies. There are two types of transformers, argument transformer and reply transformer:. Transformers for hmset and hgetall were mentioned above, and the transformer for mset is similar to the one for hmset :. Another useful example of a reply transformer is one that changes hgetall to return array of arrays instead of objects which avoids an unwanted conversation of hash keys to strings when dealing with binary hash keys:.

Redis supports the MONITOR command, which lets you see all commands received by the Redis server across all client connections, including from other client libraries and other computers. The monitor method returns a monitor instance. After you send the MONITOR command, no other commands are valid on that connection. ioredis will emit a monitor event for every new monitor message that comes across.

The callback for the monitor event takes a timestamp from the Redis server and an array of command arguments. Here is another example illustrating an async function and monitor. disconnect :. Redis 2. It's different from KEYS in that SCAN only returns a small number of elements each call, so it can be used in production without the downside of blocking the server for a long time.

However, it requires recording the cursor on the client side each time the SCAN command is called in order to iterate through all the keys correctly. Since it's a relatively common use case, ioredis provides a streaming interface for the SCAN command to make things much easier. A readable stream can be created by calling scanStream :.

scanStream accepts an option, with which you can specify the MATCH pattern, the TYPE filter, and the COUNT argument:. Just like other commands, scanStream has a binary version scanBufferStream , which returns an array of buffers. It's useful when the key names are not utf8 strings. There are also hscanStream , zscanStream and sscanStream to iterate through elements in a hash, zset and set. The interface of each is similar to scanStream except the first argument is the key name:. You can learn more from the Redis documentation.

Useful Tips It's pretty common that doing an async task in the data handler. We'd like the scanning process to be paused until the async task to be finished. Stream pause and Stream resume do the trick. For example if we want to migrate data in Redis to MySQL:. By default, ioredis will try to reconnect when the connection to Redis is lost except when the connection is closed manually by redis.

disconnect or redis. It's very flexible to control how long to wait to reconnect after disconnection using the retryStrategy option:. retryStrategy is a function that will be called when the connection is lost. The argument times means this is the nth reconnection being made and the return value represents how long in ms to wait to reconnect.

When the return value isn't a number, ioredis will stop trying to reconnect, and the connection will be lost forever if the user doesn't call redis. connect manually. When reconnected, the client will auto subscribe to channels that the previous connection subscribed to. This behavior can be disabled by setting the autoResubscribe option to false.

And if the previous connection has some unfulfilled commands most likely blocking commands such as brpop and blpop , the client will resend them when reconnected. This behavior can be disabled by setting the autoResendUnfulfilledCommands option to false. By default, all pending commands will be flushed with an error every 20 retry attempts. That makes sure commands won't wait forever when the connection is down.

You can change this behavior by setting maxRetriesPerRequest :. Set maxRetriesPerRequest to null to disable this behavior, and every command will wait forever until the connection is alive again which is the default behavior before ioredis v4. Besides auto-reconnect when the connection is closed, ioredis supports reconnecting on certain Redis errors using the reconnectOnError option. Here's an example that will reconnect when receiving READONLY error:.

This feature is useful when using Amazon ElastiCache instances with Auto-failover disabled. On these instances, test your reconnectOnError handler by manually promoting the replica node to the primary role using the AWS console. The following writes fail with the error READONLY. Using reconnectOnError , we can force the connection to reconnect on this error in order to connect to the new master. Furthermore, if the reconnectOnError returns 2 , ioredis will resend the failed command after reconnecting.

On ElastiCache instances with Auto-failover enabled, reconnectOnError does not execute. Instead of returning a Redis error, AWS closes all connections to the master endpoint until the new primary node is ready. ioredis reconnects via retryStrategy instead of reconnectOnError after about a minute. On ElastiCache instances with Auto-failover enabled, test failover events with the Failover primary option in the AWS console. The Redis instance will emit some events about the state of the connection to the Redis server.

You can also check out the Redis status property to get the current connection status. When a command can't be processed by Redis being sent before the ready event , by default, it's added to the offline queue and will be executed when it can be processed. You can disable this feature by setting the enableOfflineQueue option to false :. Redis doesn't support TLS natively, however if the redis server you want to connect to is hosted behind a TLS proxy e. stunnel or is offered by a PaaS service that supports TLS connection e.

com , you can set the tls option:. Warning TLS profiles described in this section are going to be deprecated in the next major version. Please provide TLS options explicitly. To make it easier to configure we provide a few pre-configured TLS profiles that can be specified by setting the tls option to the profile's name or specifying a tls.

profile option in case you need to customize some values of the profile. ioredis supports Sentinel out of the box. It works transparently as all features that work when you connect to a single node also work when you connect to a sentinel group. Sentinels have a default port of The arguments passed to the constructor are different from the ones you use to connect to a single node, where:. ioredis guarantees that the node you connected to is always a master even after a failover.

When a failover happens, instead of trying to reconnect to the failed node which will be demoted to slave when it's available again , ioredis will ask sentinels for the new master node and connect to it. All commands sent during the failover are queued and will be executed when the new connection is established so that none of the commands will be lost. It's possible to connect to a slave instead of a master by specifying the option role with the value of slave and ioredis will try to connect to a random slave of the specified master, with the guarantee that the connected node is always a slave.

If the current node is promoted to master due to a failover, ioredis will disconnect from it and ask the sentinels for another slave node to connect to. If you specify the option preferredSlaves along with role: 'slave' ioredis will attempt to use this value when selecting the slave from the pool of available slaves.

The value of preferredSlaves should either be a function that accepts an array of available slaves and returns a single result, or an array of slave values priorities by the lowest prio value first with a default value of 1. Besides the retryStrategy option, there's also a sentinelRetryStrategy in Sentinel mode which will be invoked when all the sentinel nodes are unreachable during connecting.

If sentinelRetryStrategy returns a valid delay time, ioredis will try to reconnect from scratch. The default value of sentinelRetryStrategy is:. Redis Cluster provides a way to run a Redis installation where data is automatically sharded across multiple Redis nodes.

You can connect to a Redis Cluster like this:. The first argument is a list of nodes of the cluster you want to connect to. Just like Sentinel, the list does not need to enumerate all your cluster nodes, but a few so that if one is unreachable the client will try the next one, and the client will discover other nodes automatically when at least one node is connected.

clusterRetryStrategy : When none of the startup nodes are reachable, clusterRetryStrategy will be invoked. When a number is returned, ioredis will try to reconnect to the startup nodes from scratch after the specified delay in ms. Otherwise, an error of "None of startup nodes is available" will be returned. The default value of this option is:. It's possible to modify the startupNodes property in order to switch to another set of nodes here:.

dnsLookup : Alternative DNS lookup function dns. lookup is used by default. It may be useful to override this in special cases, such as when AWS ElastiCache used with TLS enabled. enableOfflineQueue : Similar to the enableOfflineQueue option of Redis class. enableReadyCheck : When enabled, "ready" event will only be emitted when CLUSTER INFO command reporting the cluster is ready for handling commands. Otherwise, it will be emitted immediately after "connect" is emitted.

scaleReads : Config where to send the read queries. See below for more details. maxRedirections : When a cluster related error e. is received, the client will redirect the command to another node. This option limits the max redirections allowed when sending a command.

The default value is retryDelayOnFailover : If the target node is disconnected when sending a command, ioredis will retry after the specified delay. If this option is a number by default, it is , the client will resend the commands after the specified time in ms. retryDelayOnTryAgain : If this option is a number by default, it is , the client will resend the commands rejected with TRYAGAIN error after the specified time in ms.

retryDelayOnMoved : By default, this value is 0 in ms , which means when a MOVED error is received, the client will resend the command instantly to the node returned together with the MOVED error.

However, sometimes it takes time for a cluster to become state stabilized after a failover, so adding a delay before resending can prevent a ping pong effect.

redisOptions : Default options passed to the constructor of Redis when connecting to a node. slotsRefreshTimeout : Milliseconds before a timeout occurs while refreshing slots from the cluster default slotsRefreshInterval : Milliseconds between every automatic slots refresh by default, it is disabled. A typical redis cluster contains three or more masters and several slaves for each master. It's possible to scale out redis cluster by sending read queries to slaves and write queries to masters by setting the scaleReads option.

scaleReads is "master" by default, which means ioredis will never send any queries to slaves. There are other three available options:. NB In the code snippet above, the res may not be equal to "bar" because of the lag of replication between the master and slaves. Every command will be sent to exactly one node.

For commands containing keys, e. GET , SET and HGETALL , ioredis sends them to the node that serving the keys, and for other commands not containing keys, e. INFO , KEYS and FLUSHDB , ioredis sends them to a random node.

Sometimes you may want to send a command to multiple nodes masters or slaves of the cluster, you can get the nodes via Cluster nodes method. Cluster nodes accepts a parameter role, which can be "master", "slave" and "all" default , and returns an array of Redis instance.

For example:. Sometimes the cluster is hosted within a internal network that can only be accessed via a NAT Network Address Translation instance.

See Accessing ElastiCache from outside AWS as an example. Almost all features that are supported by Redis are also supported by Redis.

Cluster , e. custom commands, transaction and pipeline. However there are some differences when using transaction and pipeline in Cluster mode:. When any commands in a pipeline receives a MOVED or ASK error, ioredis will resend the whole pipeline to the specified node automatically if all of the following conditions are satisfied:. Internally, when a node of the cluster receives a message, it will broadcast the message to the other nodes.

ioredis makes sure that each message will only be received once by strictly subscribing one node at the same time. If some of nodes in the cluster using a different password, you should specify them in the first parameter:. In standard mode, when you issue multiple commands, ioredis sends them to the server one by one. As described in Redis pipeline documentation, this is a suboptimal use of the network link, especially when such link is not very performant.

The TCP and network overhead negatively affects performance. Commands are stuck in the send queue until the previous ones are correctly delivered to the server. This is a problem known as Head-Of-Line blocking HOL. It can be enabled by setting the option enableAutoPipelining to true.

No other code change is necessary. In auto pipelining mode, all commands issued during an event loop are enqueued in a pipeline automatically managed by ioredis.

At the end of the iteration, the pipeline is executed and thus all commands are sent to the server at the same time. This feature can dramatically improve throughput and avoids HOL blocking. While an automatic pipeline is executing, all new commands will be enqueued in a new pipeline which will be executed as soon as the previous finishes. When using Redis Cluster, one pipeline per node is created. Commands are assigned to pipelines according to which node serves the slot.

A pipeline will thus contain commands using different slots but that ultimately are assigned to the same node.

Note that the same slot limitation within a single command still holds, as it is a Redis limitation. When Node receives requests, it schedules them to be processed in one or more iterations of the events loop. All commands issued by requests processing during one iteration of the loop will be wrapped in a pipeline automatically created by ioredis.

When all events in the current loop have been processed, the pipeline is executed and thus all commands are sent to the server at the same time. While waiting for pipeline response from Redis, Node will still be able to process requests. All commands issued by request handler will be enqueued in a new automatically created pipeline.

This pipeline will not be sent to the server yet. As soon as a previous automatic pipeline has received all responses from the server, the new pipeline is immediately sent without waiting for the events loop iteration to finish. This approach increases the utilization of the network link, reduces the TCP overhead and idle times and therefore improves throughput. All the errors returned by the Redis server are instances of ReplyError , which can be accessed via Redis :.

By default, the error stack doesn't make any sense because the whole stack happens in the ioredis module itself, not in your code. So it's not easy to find out where the error happens in your code. ioredis provides an option showFriendlyErrorStack to solve the problem. When you enable showFriendlyErrorStack , ioredis will optimize the error stack for you:.

This time the stack tells you that the error happens on the third line in your code. Pretty sweet! However, it would decrease the performance significantly to optimize the error stack. So by default, this option is disabled and can only be used for debugging purposes. You shouldn't use this feature in a production environment. FLUSH ALL will be invoked after each test, so make sure there's no valuable data in it before running tests.

If your testing environment does not let you spin up a Redis server ioredis-mock is a drop-in replacement you can use in your tests. It aims to behave identically to ioredis connected to a Redis server so that your integration tests is easier to write and of better quality. And since I'm not a native English speaker, if you find any grammar mistakes in the documentation, please also let me know. Open source is hard and time-consuming. If you want to invest in ioredis's future you can become a sponsor and make us spend more time on this library's improvements and new features.

npm i ioredis. Git github. Completely compatible with Redis 7. Features ioredis is a robust, full-featured Redis client that is used in the world's biggest online commerce company Alibaba and many other awesome companies. High performance 🚀.

Delightful API 😄. It works with Node callbacks and Native promises. Transformation of command arguments and replies.

Transparent key prefixing. Abstraction for Lua scripting, allowing you to define custom commands. Supports binary data. Supports TLS 🔒. Supports offline queue and ready checking.

Supports ES6 types, such as Map and Set. Supports GEO commands 📍. Supports Redis ACL. Sophisticated error handling strategy. Supports NAT mapping.

Supports autopipelining. js Version Redis Version 5. Redis Cloud: From the creators of Redis Experience the best Redis. Sign Up Now! Medis: Redis GUI for macOS Looking for a Redis GUI for macOS, Windows and Linux? Medis is an open-sourced, beautiful, easy-to-use Redis GUI management application.

Medis 1 is open sourced on GitHub Quick Start Install npm install ioredis. js callback style redis. error err ; } else { console. get "mykey". zadd "sortedSet" , 1 , "one" , 2 , "dos" , 4 , "quatro" , 3 , "three" ; redis. set "mykey" , "hello" , "EX" , 10 ;. round Math. publish channel , JSON. stringify message ; console. log channel , message ; } ;. psubscribe "pat? await listenForMessage messages [ messages.

length - 1 ] [ 0 ] ; } listenForMessage ;. set "foo" , Buffer. from [ 0x62 , 0x75 , 0x66 ] ;. pipeline ; pipeline. set "foo" , "bar" ; pipeline. del "cc" ; pipeline. set "foo" , "bar". del "cc". get "foo". exec ; promise. pipeline [ [ "set" , "foo" , "bar" ] , [ "get" , "foo" ] , ]. set "foo". set "foo" , "new value". multi { pipeline : false } ; redis.

set "foo" , "bar" ; redis. get "foo" ; redis. multi [ [ "set" , "foo" , "bar" ] , [ "get" , "foo" ] , ]. exec ;. myecho "k1" , "k2" , "a1" , "a2". mset { k1 : "v1" , k2 : "v2" } ; redis. mset new Map [ [ "k3" , "v3" ] , [ "k4" , "v4" ] , ] ; redis. hset "h1" , Buffer. from [ 0x01 ] , Buffer. from [ 0x02 ] ; redis. from [ 0x03 ] , Buffer. from [ 0x04 ] ; redis. monitor ; monitor. on "monitor" , console. disconnect ; } ;.

scanStream ; stream. log resultKeys [ i ] ; } } ; stream. log "all keys have been visited" ; } ;. hscanStream "myhash" , { match : "age:?? pause ; Promise. all resultKeys. map migrateKeyToMySQL. resume ; } ; } ; stream.

log "done migration" ; } ;. readFileSync "cert. com" ;. set "foo" , "bar" ;.

In computer science , binary search , also known as half-interval search , [1] logarithmic search , [2] or binary chop , [3] is a search algorithm that finds the position of a target value within a sorted array. If they are not equal, the half in which the target cannot lie is eliminated and the search continues on the remaining half, again taking the middle element to compare to the target value, and repeating this until the target value is found. If the search ends with the remaining half being empty, the target is not in the array.

However, the array must be sorted first to be able to apply binary search. There are specialized data structures designed for fast searching, such as hash tables , that can be searched more efficiently than binary search.

However, binary search can be used to solve a wider range of problems, such as finding the next-smallest or next-largest element in the array relative to the target even if it is absent from the array. There are numerous variations of binary search. In particular, fractional cascading speeds up binary searches for the same value in multiple arrays.

Fractional cascading efficiently solves a number of search problems in computational geometry and in numerous other fields. Exponential search extends binary search to unbounded lists. The binary search tree and B-tree data structures are based on binary search. Binary search works on sorted arrays. Binary search begins by comparing an element in the middle of the array with the target value.

If the target value matches the element, its position in the array is returned. If the target value is less than the element, the search continues in the lower half of the array. If the target value is greater than the element, the search continues in the upper half of the array.

By doing this, the algorithm eliminates the half in which the target value cannot lie in each iteration. The procedure may be expressed in pseudocode as follows, where the variable names and types remain the same as above, floor is the floor function , and unsuccessful refers to a specific value that conveys the failure of the search. This may change the result if the target value appears more than once in the array. Some implementations leave out this check during each iteration.

This results in a faster comparison loop, as one comparison is eliminated per iteration, while it requires only one more iteration on average. Hermann Bottenbruch published the first implementation to leave out this check in The procedure may return any index whose element is equal to the target value, even if there are duplicate elements in the array. The regular procedure would return the 4th element index 3 in this case. However, it is sometimes necessary to find the leftmost element or the rightmost element for a target value that is duplicated in the array.

In the above example, the 4th element is the leftmost element of the value 4, while the 5th element is the rightmost element of the value 4. The alternative procedure above will always return the index of the rightmost element if such an element exists. To find the leftmost element, the following procedure can be used: [10]. To find the rightmost element, the following procedure can be used: [10]. The above procedure only performs exact matches, finding the position of a target value.

However, it is trivial to extend binary search to perform approximate matches because binary search operates on sorted arrays. For example, binary search can be used to compute, for a given value, its rank the number of smaller elements , predecessor next-smallest element , successor next-largest element , and nearest neighbor.

Range queries seeking the number of elements between two values can be performed with two rank queries. In terms of the number of comparisons, the performance of binary search can be analyzed by viewing the run of the procedure on a binary tree.

The root node of the tree is the middle element of the array. The middle element of the lower half is the left child node of the root, and the middle element of the upper half is the right child node of the root. The rest of the tree is built in a similar fashion. Starting from the root node, the left or right subtrees are traversed depending on whether the target value is less or more than the node under consideration.

The worst case may also be reached when the target element is not in the array. In the best case, where the target value is the middle element of the array, its position is returned after one iteration. In terms of iterations, no search algorithm that works only by comparing elements can exhibit better average and worst-case performance than binary search. The comparison tree representing binary search has the fewest levels possible as every level above the lowest level of the tree is filled completely.

This is the case for other search algorithms based on comparisons, as while they may work faster on some target values, the average performance over all elements is worse than binary search.

By dividing the array in half, binary search ensures that the size of both subarrays are as similar as possible. Binary search requires three pointers to elements, which may be array indices or pointers to memory locations, regardless of the size of the array.

The average number of iterations performed by binary search depends on the probability of each element being searched. The average case is different for successful searches and unsuccessful searches.

It will be assumed that each element is equally likely to be searched for successful searches. For unsuccessful searches, it will be assumed that the intervals between and outside elements are equally likely to be searched. In the binary tree representation, a successful search can be represented by a path from the root to the target node, called an internal path.

The length of a path is the number of edges connections between nodes that the path passes through. The internal path length is the sum of the lengths of all unique internal paths. Since there is only one path from the root to any single node, each internal path represents a search for a specific element. For example, in a 7-element array, the root requires one iteration, the two elements below the root require two iterations, and the four elements below require three iterations.

In this case, the internal path length is: [17]. Unsuccessful searches can be represented by augmenting the tree with external nodes , which forms an extended binary tree.

If an internal node, or a node present in the tree, has fewer than two child nodes, then additional child nodes, called external nodes, are added so that each internal node has two children.

By doing so, an unsuccessful search can be represented as a path to an external node, whose parent is the single element that remains during the last iteration.

An external path is a path from the root to an external node. The external path length is the sum of the lengths of all unique external paths. Each iteration of the binary search procedure defined above makes one or two comparisons, checking if the middle element is equal to the target in each iteration. Assuming that each element is equally likely to be searched, each iteration makes 1. A variation of the algorithm checks whether the middle element is equal to the target at the end of the search.

On average, this eliminates half a comparison from each iteration. This slightly cuts the time taken per iteration on most computers.

However, it guarantees that the search takes the maximum number of iterations, on average adding one iteration to the search.

In analyzing the performance of binary search, another consideration is the time required to compare two elements. For integers and strings, the time required increases linearly as the encoding length usually the number of bits of the elements increase.

For example, comparing a pair of bit unsigned integers would require comparing up to double the bits as comparing a pair of bit unsigned integers. The worst case is achieved when the integers are equal. This can be significant when the encoding lengths of the elements are large, such as with large integer types or long strings, which makes comparing elements expensive.

Furthermore, comparing floating-point values the most common digital representation of real numbers is often more expensive than comparing integers or short strings.

On most computer architectures, the processor has a hardware cache separate from RAM. Since they are located within the processor itself, caches are much faster to access but usually store much less data than RAM. Therefore, most processors store memory locations that have been accessed recently, along with memory locations close to it. For example, when an array element is accessed, the element itself may be stored along with the elements that are stored close to it in RAM, making it faster to sequentially access array elements that are close in index to each other locality of reference.

On a sorted array, binary search can jump to distant memory locations if the array is large, unlike algorithms such as linear search and linear probing in hash tables which access elements in sequence. This adds slightly to the running time of binary search for large arrays on most systems. In addition, sorted arrays can complicate memory use especially when elements are often inserted into the array.

Binary search can be used to perform exact matching and set membership determining whether a target value is in a collection of values. There are data structures that support faster exact matching and set membership.

Linear search is a simple search algorithm that checks every record until it finds the target value. Linear search can be done on a linked list, which allows for faster insertion and deletion than an array. Binary search is faster than linear search for sorted arrays except if the array is short, although the array needs to be sorted beforehand.

There are operations such as finding the smallest and largest element that can be done efficiently on a sorted array but not on an unsorted array. A binary search tree is a binary tree data structure that works based on the principle of binary search. The records of the tree are arranged in sorted order, and each record in the tree can be searched using an algorithm similar to binary search, taking on average logarithmic time.

Insertion and deletion also require on average logarithmic time in binary search trees. This can be faster than the linear time insertion and deletion of sorted arrays, and binary trees retain the ability to perform all the operations possible on a sorted array, including range and approximate queries.

However, binary search is usually more efficient for searching as binary search trees will most likely be imperfectly balanced, resulting in slightly worse performance than binary search. This even applies to balanced binary search trees , binary search trees that balance their own nodes, because they rarely produce the tree with the fewest possible levels. Binary search trees lend themselves to fast searching in external memory stored in hard disks, as binary search trees can be efficiently structured in filesystems.

The B-tree generalizes this method of tree organization. B-trees are frequently used to organize long-term storage such as databases and filesystems. For implementing associative arrays , hash tables , a data structure that maps keys to records using a hash function , are generally faster than binary search on a sorted array of records. Binary search also supports approximate matches. Some operations, like finding the smallest and largest element, can be done efficiently on sorted arrays but not on hash tables.

A related problem to search is set membership. Any algorithm that does lookup, like binary search, can also be used for set membership.

attname this is set up by Field. In terms of the USD object model, an API schema is one that derives from UsdAPISchemaBase , but not from its subclass UsdTyped. MaterialBindingAPI greenMarbleGeom. There are three main situations where Django needs to interact with the database backend and fields:. A simple example of an attribute that has both an authored default and two timeSamples in the same primSpec:.

Categories:

• Forex
• Forex Brokers
• Forex Bitcoin
• Binary Options online
• Binary Options